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Abstract 


A  fonnal  method  for  systmnatically  mtegtatiiig  gmieral-puipose  software  modules  into 
efficient  ^sterns  is  presaited.  The  integration  is  aocompUshed  dirougb  adjustment  of 
abstract  interfaces  and  transformation  of  die  underiying  data  xqitesentaticms.  Themediod 
provides  die  software  designer  with  die  ability  to  delay  or  revise  design  decisions  in  cases 
where  it  is  difficult  to  reach  an  a  priori  agreement  on  interfaces  and/or  data  iqnesentadtms. 

lb  demonstrate  die  method,  die  develo(»nent  of  a  text  buffer  for  a  simple  interacdve 
text  editor  is  pven.  Foreach  basic  operadcm  cm  the  text  buffiBr,anatural  and  effidratchdce 
of  data  xqireaentatioD  is  made.  This  organizes  the  operadmis  into  several  **comp(xiNits,” 
widi  eadi  component  contaimng  diose  operadoos  using  die  same  data  rqpreseotadon.  The 
components  are  dien  combined  using  formal  program-manipuladon  methods  to  obtain  an 
cffident  compomte  representation  diatsiqiportsaill  of  die  operatkxis. 

This  qyoadi  provides  meaningful  support  for  later  adaptation.  Should  a  new  editing 
operation  be  added  at  a  later  dme,  the  initial  compoomits  can  be  reused  in  another  cmn- 
bhung  process,  thereby  obtaining  a  new  composite  rqaesentadon  diat  works  for  all  of  the 
operadoos  jncliuHng^  new  one.  There  are  also  ramificadoos  for  die  q^licadonttf  fonnal 
methods  to  laiger-acale  systems,  as  dus  method  can  be  qiplied  to  die  manipuladra  of  the 
interfaces  between  modules  in  larger  software  tystmns. 
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Chapter  1 
Introduction 


1.1  The  Problem  of  Organizing  Interfaces 

The  aiganizati<Hi  of  interfaces  among  system  compcxients  is  a  key  task  in  the  construction 
and  managonent  of  largovscale  software  systons.  For  many  large  systms»  a  principal 
source  of  risk  is  in  making  die  decisumscmicenDing  the  placonent  of  these  interfaces  [11] 
—  in  other  words,  how  the  comp(»ents  are  to  be  organized  into  an  integrated  software 
system.  Language  features  for  modularity,  including  various  type  systmns,  provide  a 
means  for  compmiait  structure  to  be  made  more  eiqilicit,  thus  fadlitadng  management  of 
systems  interfaces  [65]. 

1  suggest  that  formal  methods  [19, 31}  can  be  tilled  to  siqiport  the  develqnnent  and 
evolution  of  larger-scale  systems  throng  the  formal  manipuladmi  of  the  int^aces  and 
cmnponents.  As  a  system  architecture  matures  and  evolves,  interfaces  and  components 
will  likely  need  to  be  adjusted  in  various  ways,  by  moving  or  shifting  computadmis  across 
interfaces,  by  introducing  new  interfaces  tt>  create  new  components,  by  combining  similar 
interfaces  to  merge  comptments,  and  so  on.  Indeed,  the  architecture  of  large  systems  is 
rarely  determined  fully  in  advance  and,  in  any  case,  evdves  npdly  as  devdopmmit  ex¬ 
perience  is  gained.  Widiin  maintenance  activities,  for  example,  60  percent  of  the  effort 
is  for  enhancements  [53].  Formal  methods  can  provide  a  basis  for  die  creatimi  of  soft¬ 
ware  toeds  diat  support  diis  kind  of  iterative  r^nemem  [4].  Such  tools  could  potentially 
reduce  die  risks,  which  are  now  very  high,  associated  widi  the  determination  of  overall 
systems  architecture  in  software  develqpment  The  risks  are  high  because  of  the  need  for 
mhancement 

Coiisider  theiriiportamproblemof  ctxnbining,  or*integrating,**  modules  that  must  share 
data.  The  possibility  ttfshaing  means  that  interacting  modules  must  agree  not  mdytm  the 
abstract  interfaces,  but  also  on  die  underlying  data  rqnesmitadtxis.  Because  architectures 
evolve,  diis  prdblmn  of  integration  usually  perasts  for  as  Umg  as  die  system  is  maintained. 

Consider,  for  mtample,  die  developmmit  of  an  intenctive  duplay-editor  A  key  sub- 
problmn  is  die  implementadoo  of  operations  on  die  text  buffer.  Thm  ate  many  possible 
representations  for  such  buffers,  for  example  a  sequence  of  diaractets,  a  sequence  of  lines, 
ttid  so  on,  and  for  ei^  qieraticxi,  one  representatfam  may  be  more  natural  or  appix^niate 
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than  anodier  Radber  than  having  to  decide  in  advance  (m  some  canpromise,  it  would  be 
ea^  to  ccdlect  into  separate  ccmptMients  the  sets  of  individual  editing  operations  diat  use, 
inastraij^orwanlimplementati(xi,tfaesame**natural**iqnesentatuns.  I  am  proposing  an 
approach  duu  involves  taking  individual  cmnponents,  each  using  its  own  “natural  rqnesen- 
tadon,”  and  combining  them  via  program  transformation  into  a  single,  ^cient,  composite 

implftfmpfplutinn 

Performing  diis  cmnpodtimi  of  components  requires  a  way  to  mediate  die  interactions 
among  diem.  Program-transformatitm  techniques  [25,  67]  can  provide  assistance  in  ac¬ 
complishing  this.  Before  discussing  this,  howevn,  we  first  consider  tbt  strategies  that  are 
curtendy  available  to  the  software  designer. 


1.2  TVaditional  Solutions 

Modem  programming  languages  such  as  Ada  [10],  Qu  [54],  Modula-2  [94],  and  Standard 
ML  [61]  provide  data  abstractuHi  and  mcqisulation  constructs  called  packages,  clusters,  or 
modules  duu  enable  one  to  define  and  enforce  dm  boundaries  sq[»rating  die  components  of 
a  software  Systran.  Modularity  facilitates  reuse  ai^  analysis  and,  whrai  properly  structured 
(either  by  design  or  dirousli  evolutum),  isolates  and  loradizes  die  revisitms  diat  occur  as  a 
Systran  is  maintained,  adiyted,  and  reused  [65].  In  diis  pqier,  I  refer  to  diese  data  abstrac¬ 
tions  as  modules.  Modules  can  be  viewed  as  implranenting  a  kind  of  (usually  complex) 
datatype  definition,  like  datatype  definiticms,  there  are  several  aspects  to  modules.  These 
are  tte  obstraa  interface,  dutt  is,  the  exported  ^pes  and  signatures  of  die  operaticms;  the 
underlying  representations  for  the  data  objects  created  and  manipulated  by  dm  module;  and 
the  implementations  of  die  operations. 

Tim  integration  of  modules  in  a  large-scale  ^stem  is  difficult  Modules  diat  interact 
most  agree  not  only  on  dm  abstract  interfaces,  but  also  on  data  rqnesentatitms  in  the  cases 
where  dmy  share  data.  Also,  as  a  software  system  evtdves,  dm  need  to  adipt  radsting 
interfaces  can  arise  [66].  Thus,  this  problem  of  integration  persists  for  as  long  as  dm  system 
is  maintained.  Because  dm  data  representations  affect  dm  interactions  among  system 
components,  I  am  motivated  to  use  dm  term  module  interface  to  refer  collectively  to  a 
module’s  abstract  interface  and  associated  data  representations. 

The  Raistint  Choices  in  Software  DevdopmenL  Oonfironted  widi  dm  problem  of  inte¬ 
grating  interfacra  in  larger-scale  systrans,  dm  software  designer  has  dm  following  chcnces: 

1.  Make  an  a  prion  correct  choice  of  abstract  interface  and  data  repiesentatimi  defini¬ 
tions  dut  suffice  for  an  anticqiated  needs. 

The  UNIX  ystem  integrates  tools  using  streams  as  a  common  interface  and  sequences 
of  characters  as  a  common  data  rgaesentation.  Traffitional  database  systrans  also 
devise  common  interfaces  and  data  rqxesentations  at  dm  beginning  of  dm  design 
process.  However,  it  is  often  dm  case  that  good  data  representations  may  be  difficult 
to  design  a  prkni,  etpecially  when  there  is  not  much  raqierience  in  ^  particular 
ipplicatkm  domain.  Once  built,  ssrstems  also  evcdve  as  users  desire  additional 
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fimctionali^whidunay  not  have  bero  anticipated  initially.  Adqnmgcomptxuaitsis 
usually  difficult  once  d^gndedsiom  are  made  and,  indeed,  die  cost  of  implementing 
change  oftmi  becomes  unmanageable.  For  mcample,  adding  a  tool  in  UNIX  diat  uses 
a  complex  internal  data  ATucture  would  involve  introducing  an  eiqiensive  nanslation 
between  it  and  dm  commcm  interface.  These  pndilems  of  risk  have  led  software 
designers  toward  iterative  and  evtdutiooary  models  of  development  [11],  but  little 
advice  is  given  on  how  to  get  frmn  (me  stage  to  the  imxt 

2.  Introduce  functions  for  translating  between  iqnesoitations  in  the  situatums  where 
die  abstract  interfaces  agree  but  the  data  representaticms  do  not 

Sqmrately  designed  modules  that  share  data  may  be  used  together  by  writing  trans¬ 
lation  functkms  diat  ccmvert  fomi  one  module*s  rqnesmitaticm  for  data  objects  to 
tbeother’s.  ifowevo;  the  effidmicy  cost  in  the  overhead  of  mapping  back  and  froth 
am(mg  modules  may  not  be  acceptable. 

Take,  for  example,  the  case  in  which  two  modules  have  been  st^parately  (iesigned  fcv 
matrix  operations,  one  for  computing  inverses  and  anodier  for  ctnnputing  detarmi- 
nants.  Let  us  assume  that  die  mtxlules  agree  (m  abstraa  interfaces,  in  which  there 
are  openttaons  to  areaie  a  matrix  and  also  to  obtain  die  elmnents  of  a  given  matrix. 
The  mcxinles  differ,  however,  oa  dieir  data  representations,  perhaps  for  reasems  of 
efficiaicy.  Tb  use  die  modules  togedmr  it  is  necessary  to  write  translatitm  functions 
duttm^  one  rnanix representatum  to  the  other.  This  can  be  done  by  (Obtaining  the 
elements  of  a  matrix  from  (xm  mtxiule  arul  dimi  creating  a  matrix  with  those  elements 
in  die  other  module. 

3.  Use  a  very-high-level  language  widiiyiproptiate  built-in  high-level  types. 

In  diis  case  data  tqsesratatioos  are  not  eiqilicidy  d^necL  Instead,  design  decisions 
regarding  data  rqnesentations  are  left  to  a  compiler  (eg.,  SETL  [79]).  Thisnieans, 
however,  diat  the  performance  of  die  implenimitatioo  and  esqnessiveness  of  the 
ptQgramminglanguage  are  timitedly  die  existing  oompOcr  technology.  Furthermote, 
if  a  designer  wants  to  develop  a  sysiron  using  ridi  abstractions  diat  will  have  reacting 
perfonnancereqoireniaits,Aen  it  seems  dun  die  designermust  be  involvedin  defining 
data  representations. 

4.  Adtqit  or  refine  the  abstract  interfaces  of  existing  modules  by  defining  new  modules 
as  metensioos  of  the  existing  ones. 

Porexanq[de,  object-orieated  techniques  can  be  used  to  define  new  ^ypes  (and  hence 
abstract  interfMes)  in  terms  of  existing  ones  [55].  Objects  having  new  type  will 
share  nmaning  with  objects  of  die  existing  type,  typically  by  inheriting  its  operations 
and  adding  somediing  more.  The  new  objects  win  alM  share  implementation  by 
direedy  reusing  the  code  for  die  existing  objects.  Unfortniuudy  diexe  is  no  formal 
wity  to  qiecializB  dud  implemaitation  in  die  context  of  die  new  type  in  order  to  (ibtain 
be^  p^ormance. 
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13  Focus  of  the  Thesis 

Eadh  of  tiieaetradirionalq^TOadies  addresses  the  problem  of  module  interface  imegratioo 
with  varying  degrees  of  success.  I  am  interested  in  how  program  transfonnation  might  be 
used  to  complonent  ormihance  them. 

13.1  Thesis 

Program  tranafimnations  can  provide  systematic  siqtport  for  integrating  general-purpose 
sojfiware  modules  into  fffidera  systems.  This  approach  also  provides  support  for  later 
odaptatiofL 

£a  particular  I  am  exploring  the  use  of  transfonnadon-based  techniques  to  ( 1 )  provide  a 
systematiciqiproachtoadiq)tingdata^pesandmodules,(2)ranovedieoveriieadoftrans- 
latkm  functions  at  runtime  through  program  manipulation,  (3)  optimize  the  performance  of 
dataQpes  using  insight  from  the  software  devel(^)er,  and  (4)  qtecialize  implemmitaticMis  to 
obtain  better  perfonnance  in  programs  with  modules  that  reuse  code  duou^  inheritamx. 
An  evaluadoo  of  die  udli^  of  the  tedmiqnes  developed  in  diis  diesis  is  given  in  Chapter  7. 

133  Approach  of  the  Thesis  Research 

1  use  program-transformadon  methods  to  integrate  module  interfaces,  yielding  efficient 
implementatiaas.  Complex  dataqqie  definitums  start  as  a  ctdlectkm  of  sqiaraie  module. 
Th^  translation  functions  among  die  modules  are  introduced  to  reach  preliminary  (or 
‘*baaeline*0  agremnent  on  data  rqnesentatkms,  and  modh/e  exteiuib/ir  defining  new  inter¬ 
faces  are  used  to  readi  agreement  on  abstract  intexfrioes.  The  initial  interfaces  are  dien 
integrated  and  ofnimired  by  using  an  extended  form  of  datatype  transformations.  This 
results  in  a  sin^  consistent  and  efficient  implementathm. 

133  A  Model  of  ^^odule  Interface”  Integration 

Letusnowconsiderdieproblemofdesigningandinqilanentingatextbufifrrdutnianip- 
ulates  dunacien  and  lines  for  a  text  editoc  (This  example  will  figure  prominmidy  in  diis 
diesis.)  fri  a  software  engineering  process,  one  d  die  early  deagn  issues,  and  one  with 
die  highest  associated  design  risk,  is  die  selection  of  die  iqaesentatkn  for  a  major  data 
structure  sndi  as  die  bufier  After  deciding  on  diis  rqnesaitation  (call  it  the  buffer),  it 
dien  remains  to  define  die  diaracier  and  line  operations,  and  finally  the  exported  bitifo 
operations.  In  die  Standard  ML  [59]  module  systm,  for  example,  ^program  for  buffer 
operations  could  be  decomposed  ii^  two  modules,  one  eadi  for  die  dunacter  and  line 
operations.  The  aim  of  modnlatization  is  to  decompose  programs  into  modules  diat  can  be 
man^mlaied  idativety  indqieodendy  (rf  each  odiec. 

Standard  ML  handles  die  proUem  of  sharing  of  data  rqiresentations  by  providing  a 
mean  for  eaqxessing  and  managing  diis  interaction  dnough  its  module  system  [42].  Indus 
example,  the  two  modules  for  dunactg  and  line  operations  would  be  combined  by  using 
diem  as  parameters  to  a  **ftmctar**  (a  parameterised  module)  that  declares  (via  a  ‘‘sharing 
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oonstraiiif  dedantkn)  that  tfiey  share  a  comnun  buffer  data  stnicture,  and  ^en  expom 
tiheboffer  operations.  (Tlie  sharing  declaratioo  is  necessary,  since  widiout  it,  diere  may  be  a 
Qfpe  conflict  in  dm  buffer  operatkms  module,  sinoe  die  buffo  inherited  dnoo^  die  dinacter 
operations  and  die  buffo  inherited  dnou^  the  line  operations  would  be  interpreted  as  two 
distinct  9pes.) 


botbr-an 


It  is,  unfortunately,  usually  difficult  to  make  such  o  priori  decisions  tm  data  representaticMis, 
especially  since  new  operations  might  be  added  affo  die  initial  design  and  implementadtm 
have  long  bemi  ccunpleted. 

An  aheniadve  spproadi  is  to  define  two  sqiarate  modules,  one  for  diaracter  t^iera- 
tkms  and  the  odier  for  line  operadons,  each  of  ixdiich  assumes  its  own  specialized  dma 
representation  for  die  buffer. 


At  some  point  diese  modules  must  be  sonmhow  integrated  if  we  are  to  use  both  character 
and  line  operadons  on  the  same  buffo:  The  problem  of  riuoing  is  now  more  complex 
since  the  modules  might  not  use  die  identical  data  r^iesentation  for  buffer.  Radier, 
diey  may  each  define  dimr  own  data  tqsesentations,udiich  are  essentially  **views**  [29]  of 
some  **canonical*’ buffo  As  indicated  earlier,  integration  could  be  achieved  by  introdndng 
functions  dm  translate  between  the  representations.  (This  would  rely  for  consisinicy  tm 
an  external  unifying  semantic-modeL) 

I  propose  a  new  qiproadt  Radier  than  mediating  die  rqnesentations  dnough  trans¬ 
lation  functions  at  runtime  (which  likely  incurs  a  significant  performance  pcmalfy),  diese 
rm^q^ings  are  incorporated  into  a  sin^  buffo  imideinentation  by  tferiving  a  new  conmum 
(and  effident)  data  rquesentation.  Rrogram-transfonnationtediniqoes  provide  a  means  to 
acoonaidish  to  by  “synthesizing”  a  new  data  rqyesrotatkm  from  die  cdtecticm  of  qiedal- 
ized  ones,  fri  esamioe,  die  translation  of  interfaces  is  “shifted”  to  an  earlier  pmnt  in  the 
computation  (or“com|iile<r).  An  example  is  presented  in  duqiter  3. 

This  qiproacfa  provides  meaningfol  support  for  later  adiytatioo.  For  example,  siq^iose 
dutt  at  some  fraure  time  die  text  buffo  implementation  is  to  be  used  in  a  new  iqqilicatioo, 
say,adia|diqrediiat  The  diqdiy  editor  may  iirqiose  new  requirements  on  die  functionality 
ofdiebidfo:  In  to  case  die  buffo  abstract  interface  must  be  extended.  Snrii  extnisicms 
could  be  accomplished  by  using,  for  examine,  inheritance  Qn  die  otject«oeiaited  sense)  to 
lesiructo  dm  Interfaces  and  add  die  iiewfiinctionaHfy.  ftogram-uansfonnationtechniques 
piovideameansoffBlfyint^yatiiigsodiextensioiis.  lnChiqaer4,lsketdioutdieindurion 
of  a  finiriied  text  buffo  in  a  displity  editor;  deriving  a  new  ^ficient  imptementatioo  die 
text  buffo  diat  takes  advantage  of  the  new  contact  of  die  diqilay  editor. 
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13.4  What  is  New 

Data  transfonnatioiu  have  been  used  to  implement  datatype  tpecificatioos  or  to  optimize 
eodstii^  programs.  The  aiqra^di  of  tids  thesis  is  novel  in  tiiat  the  leaearch  eximids  data 
tnmsfonnationshyintrododng  transformation  technignes  far  module  interface  design.  This 
«wnihl««  the  iipplfeiitiAn  of  tmnafinmiiitinn  tBChnigues  tO  the  development  aAapatinn  of 
*TaigBr-scale  tystems”  [20].  Small-scale  tystmns  that  deal  primarily  witii  algorithm  devd- 
opment  have  been  studied  mdensivdy.  In  this  next  siq>iq>  I  focus  on  data  rqneaentatums. 
This  dieris  does  not  address  all  issues  of  large-scale  tystem  design,  but  ratiier  makes  a 
contribution  in  extending  tile  current  tedmiques  by  apfdying  program  transfarmaticm  to  die 
integration  of  module  interfaces.  A  study  of  die  derivation  of  an  interactive  di^lay-editor 
is  shown  that  illustrates  die  hard  problems  oi  module  intetfsce  integration  diat  occur  in 
software  devdqratcnt  A  framework  for  describing  die  transformation  techniques  is  then 
established. 

Sdving  this  integration  problem  not  only  enhances  existing  approaches,  but  also  may 
lead  to  new  possibilities  in  designing  systems.  For  instance,  abstract  datatypes  are  good 
for  iadatingdients  from  change,  but  not  for  promoting  enhancement  and  adiqrtation  [30]. 
Tins  dieris  researcli  could  lead  to  a  new  way  of  diinking  about  module  constnicticm  where 
we  imagine  building  more  flexible  systems  dut  riiare  data. 

This  thesis  suggests  a  paradigm  for  datatype  implementation  Ity  "componmits.**  Some¬ 
times  it  is  difficult  to  design  types  or  antictyate  future  needs.  Instead  of  introducing  a  type 
and  anticipating  all  necessary  operators,  die  operations  are  dcarigned  as  we  discover  the 
need  for  them  in  the  program  using  die  datatype.  The  rqaesmitations  are  selected  based 
on  the  needed  operations.  This  diesis  also  suggests  a  paradigm  of  tystemimpkmentaticm 
by  modules  triiere  we  use  tranaformationtedmiques  to  get  better  performance  dian  simply 
rensingcode.  The  module  transformation  system  provides  a  way  to  mangnilaie  die  modules 
and  to  dumge  dm  coheriveness  and  die  couplings  the  modules  [bS]. 


1.4  Structure  of  the  Thesis 

I  imroduce  dm  module  interface  transformation  tystem  in  Chapter  2.  Rtst,  badcground 
it^onnation  on  data  transfannation  is  presented  dun  describes  dm  progress  made  in  devd- 
oping  data  transformations.  1  continue  dm  progression  widi  teduriques  for  datatypes  and 
modides.  The  transfarination  system  is  introduced  informally  in  two  parts.  Firstlennmer- 
ate  a  ooQeciaon  of  tnodnle  ttmufonnation  roles  that  ate  nse^  far  atyusting  interfaces  and 
data  reprasentations.  Then  I  demonstrate  how  dm  roles  are  used  in  different  arategies  to 

itn|U.w»Maif  hy  ffnwipnwiiiitg,  mmI  gfiU*i«aiey  mf  fyrtifmf. 

]hdmtwodMgpiendiatfoikiw,Ipreaeatanexanq>lediatisoenteredaroniiddmderivation 
of  an  interactive  diqplay-e&or  to  demonstrate  dm  derivation  process  and  techniques.  In 
Qupter  3, 1  design  an  editor  text  buffer  to  tDostrate  dm  int^tmian  and  aihqpauion  of 
IQ  hBpiement  datatypes.  Then  in  Qupter  4^  1  add  a  display  to  dm  hntfcr  to 
iHtHnaae  dm  bnildihtg  of  modides  from  other  modules  and  to  show  how  to  increase  dm 
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1  interpret  the  lesahs  of  die  editor  derivation  in  Qiapier  S  widi  a  diacnsaion  of  the 
altenadves  in  iitt^radog  die  modnte  interfaces  diat  aie  a^^lable  to  die  loftwaie  designer 
at  the  design  level  and  die  inqikmentatioa  kvd.  Also  discnssed  are  the  criteria  diat 
die  software  designer  might  use  to  diose  a  pacific  alternative,  the  cost  ci  the  varuras 
altenoadves,  and  die  potential  for  scaling. 

After  the  example,  I  examine  the  module  interface  transformation  system  in  C3iapter  6 
to  establish  a  ftamewatk  far  describing  die  derivation  process  and  techniques.  Providing  a 
fiameworit  enhances  the  understMidingof  die  terms  used  infarmally,  provides  structure  to 
aid  the  software  designer  in  using  die  iqiproachttid  is  an  important  stqi  towards  automating 
dieqfatem.  htoy  of  the  terms  that  are  introduced  in  the  example,  such  as  “componrot,” 
“ttanslation  function,**  and  **aggregtte**  are  given  a  predse  meaning.  The  dedsicm  was 
made  to  qdit  die  descrqition  of  die  module  transfarmation  system  into  two  duqiters  in  order 
to  better  motivate  the  system  widi  an  exanqde  before  going  into  the  technical  details. 

In  duqiter  7, 1  evaluate  the  module  transformation  system  by  comparing  it  to  traditi(»al 
qiproaches  and  cnrrentreaeardi  in  software  development,  and  then  examine  the  qiplicarions 
in  vdiidi  the  tedmiques  would  prove  uaeftiL 

RnaUy,  in  Chapter  8, 1  condude  the  thesis  widi  a  summary  and  evaluation  o£  the 
contribtttions  of  die  diesis.  This  thesis  has  eiqilored  a  module  interface  transformatitni 
system  widioat  medhanized  aqiport  tritich  makes  it  difficult  to  apply  die  techniques  to 
larger  systems.  Solutions  to  oidmize  die  derivation  process  and  to  bdld  an  automated 
system  are  discussed. 

Appendix  A  summarises  die  notation  used  in  die  examples.  Appendix  B  is  a  glossary 
of  common  tennindogy.  The  remaining  qqpcndices  include  details  about  die  derivatim 
and  proof  steps. 


Chapter  1.  Introduction 


Chapter  2 


Module  Interface  lyansformation 
System 


The  general  strategy  for  constructing  systems  nang  the  module  interface  transformation 
system  is  iUnstrated  in  Hgnre  2.1.  Tte  process  starts  witii  die  design  of  die  top-level 
aggregate  ^ledfication.  The  software  dedgner  udio  wishes  to  design  a  complex  syston 
is  able  to  deconqiose  the  problem  into  components  tiut  best  model  diat  portion  of  the 
problem.  This  aggregate  qiecification  is  used  in  the  integration  phase  to  produce  an 
aggregate  definition,  The  aggregate  definition  is  in  a  format  tqxm  which  data  translati(Mis 
can  be  performed  to  obtain  an  executable  promote.  Then  additional  transformations  such 
as  incmporate,  leteose,  and  can  be  performed  to  optimize  the  prototype  into  an 

eSdeatintidementation.  Later  on  die  software  designer  may  wish  to  introduce  additional 
ftmctionaliQr  in  die  adept  phase.  The  design^  integrate^  and  odapr  phases  are  siqiported 
by  die  metfaodcdogy  deWloped  in  Section  2.1.  The  promote  and  idiases  are 

supported  by  die  module  transformation  rules  develop  in  Section  23.  These  {duoes  will 
be  elaborated  as  we  progress  through  tins  duyter. 

We  begin  in  Section  2.1  t^ddh  demonstrates  hofw  die  module  transformaticms  are  used 
in  tfiffierent  strategies  to  imidement  datatypes  by  components  and  to  increase  the  effidmicy 
of  module  qpsiems.  Tb  give  os  die  necessary  background.  Section  23  contains  information 
on  data  transformatioos  dial  is  necessary  to  understand  die  module  transformation  rules. 
Previoosworic  on  data  transformation  foQowsaprogression  of  increasing  sDpport  for  larger- 
scale  systems.  Initial  transformations  affected  the  data  rqnesemations  of  the  parameters 
of  ftmctions;  later  transformation  tedmkpies  were  iqpidied  to  abstract  data^pes.  Tbepro- 
greaskm  continues  in  Section  23  udiere  I  introduce  applying  transformation  tedmiques  to 
niodnk  systems,  and  enumerate  Ae  tnmsformation  in^i^  on  abstract  inteiftioes  and  data 
icpnaentations.  (A  fiainewotk  for  descrilting  die  transformmioos  is  presented  in  Cluq>- 
lerd.)  Section  2A  ties  togeter  die  previous  sections  where  I  describe  hofw  these  integration 
mediods  and  die  modide  transformation  rules  are  used  in  die  software  devetopmem  process. 
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Hgiire2.1:  Stniegy  far  Ooostnictiiig  Systems 
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Hgure2^:  Buffo*  Definitim 


2.1  Module  Transformation  in  Software  Development 

Wb  fove  briefly  seen  in  Sectkm  13.3  an  iQ>{>roech  to  Ac  derivatkn  of  an  editor  buffo  that 
is  pert  of  die  devdopment  of  an  interactive  tnct  editor,  and  in  Rgme  2.1  a  general  strategy 
for  oonstroctingsystenu  using  diisqiproach.  Using  dus  strategy,  d»  editor  is  designed  as  a 
colkctkin  of  sqwgate  modules,  eadi  of  tririch  implements  subsets  of  the  buffo  operatiCTM 
efficiendy(Rgure23).  There  ate  dnee  modules:  Bufiicpreseatingabuffoasasequrace 
of  dugacterswidi  an  eaqilicit  index  for  die  poiitttriiereeditingtalces  place;  Bufaigpresenting 
a  buffo  as  a  pair  of  sequences,  oorteqxmding  to  the  duracters  to  die  left  and  to  die  ri^t 
of  the  point  of  editing  and  Buf  3  rqxeseating  a  buffo  as  a  sequence  of  lines  widi  an  index 
consisting  of  a  line  and  diaracterposidoa  for  the  point  of  editing.  Compatibili^  maps  ett 
introduced  to  estabUdi  a  oonespondmice  among  the  data  rqpiesentatioiis.  This  coUecdon 
of  modules  is  dien  integrated.  Using  an  extended  form  of  data  transfcrmadonsCdevdoped 
in  the  fdknring  sections)  yields  an  executable  pnaotype  die  first  mcecutable  Systran); 

ftirther  specialization  dien  yields  a  inore  efficient  ingiieinentation. 

The  following  two  aectiomt  describe  diese  techniques  for  integrating  datatypes  (Sec¬ 
tion  2.1.1)  and  modules  (Section  2.13).  Each  section  indudes  a  description  of  the  mediod, 
an  example,  and  a  pointer  to  how  the  mediod  is  used  in  die  editor  example  in  die  fdlowing 
twoduiptets.  The  examples  are  extracted  from  die  diqilay-editor  d^vatitn  in  die  two 
duqNersdiatfdlow.  On  first  reading  it  is  best  to  skim  dnongh  die  exanqile.  The  intentimi 
hereistoshowdie‘*strnctnre**ofdiemediod.  Details  about  die  notation,  die  diqriay  editor, 
and  die  mediod  will  be  learned  sriien  we  return  to  die  exanqries  in  die  editor  derivatkm.  Wt 
also  leturn  to  diese  transformation  mediods  and  see  a  more  formal  defiirition  in  ChaiMBr  6. 


NoHriiOB  Md  Nsarfiv  Coavcntioaa.  Names  of  9pes  and  operations  have  the  name  of 
the  component  in  sriritAdi^  were  defined  jxepended  in  order  to  resdve  ambiguities.  Fbr 
exaBOfle,  if  die  components  define  a  ^pe  buf  ffien  Buf  i  Jtmf  refers  to  die  type  defined 
in  die  first  component  To  eidianoe  die  leadiririliQr  of  die  examples,  these  "qualified” 
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names  aie  abbreviated  omitting  die  ccimpoQait  name,  and  using  die  component  number 
as  a  sobscrqit  widi  die  type  or  operatum  name.  For  eacanqile,  buf  i  and  move-rlghti  are 
abbreviadons  for  BufiJauf  and  Biifi jnove^hL  The  expression  local... in... end”  is 
used  to  sqpatate  die  iniUic  operadons  (diat  appear  after  die  keyword  in)  from  die  private 
operations  (diat  appear  after  the  keyword  local)  which  are  us^  hy  the  imblic  fonctkms 
bat  not  intended  for  use  elsewhere.  It  is  advisable  for  die  reader  to  look  first  at  the  public 
fanedons  and  tfaeo  at  die  private  functions  if  additional  details  are  desired. 

2.1.1  Datatypes 

The  text  bufoexample  suggests  apacadigm  for  datatype  implementation  by  “components.” 
The  baling  bloclcs  for  die  paradigm  are  emnponents  diat  implement  parts  of  a  type. 
Sometimes  it  is  difficult  to  design  types  or  antidpate  future  needs.  Instead  of  introdu^g 
a  ^pe  and  anticiparing  all  necessary  operators,  die  qpeacadmis  are  designed  as  we  discovCT 
die  need  for  diem  in  die  program  using  die  dataQrpe.  Ifore,  we  use  modules  to  implement 

bl^rath^  a  CoOectkin  of  Cmnponents 

We  ssy  t^iat  we  mean  by  aggregating  a  number  of  conqionmits  into  a  cmnposite  data 
structure  by  defining  an  aggngau  speculation.  Brst  we  must  supplement  our  notatkm 
(baaed  on  Standard  ML  [42])  with  axioms  to  describe  die  properties  of  the  data  aggregate. 
Extended  ML  [72|  gives  die  developer  dds  ability  to  add  axioms  to  structures  and  signatures. 
Axioms  are  expressioos  of  boolean  type  and  are  built  using  die  functions  of  first  order  logic. 

For  die  purposes  of  dus  definition,  we  consider  a  system  consisting  of  two  comptments 
(ndudi  *Yqiresenf*  die  same  obgect),  andoonfider  die  case  t^iere  an  eperatian  is  defined 
in  die  second  component  The  oonsisttaicy  relations,  mapj,  ensure  the  consistency  among 
diese  components.  A  pragection,  proj^,  oi  an  aggregate  data  object  yidkis  an  object  of 
a  particular  component  a^  each  such  component  object  is  related  to  other  componmit 
objects  by  a  consistaicyidatioa.  The  following  two  axioms  describe  die  properties  of  the 
aggregate. 

sadaHipfeii(op(a9g))  -  opjOtrahCagg)) 

mapj  pro|,(aOT)  Pfoji(op(agg))  mapj  p»ti|,(op(agg)) 

The  first  axiom  defines  the  bdmvior  of  the  operation  on  the  aggregate  data^pe  induced  by 
the  second  oooqionent  operation,  op^.  The  ronaining  axiom  misuresdut  after  qiplying  die 
operation,  all  of  die  oonqionents  remain  consistent  There  is  a  set  of  sodi  axioms  for  eadi 
operation  defined.  Onby  one  set  is  shown  for  iHnstrative  purposes. 

Ifowdiatweliaveraiablishedwhatismeaatbyaggr^atingannmberofcompooaits,we 
define  how  dm  aggi^aiD  is  hnidemenied.  Oivwi  a  coltection  of  components  and  compati- 
bfii9  nMgw,  an  nKgrefOtr  tipbiitiofi  is  produced  dud  is  amenable  to  module  transformations 
CPigereli^  The  conqmiaiifiQr  mips,  map^^,  reflect  die  consistency  relations  and  define 
heiw  to  n^  die  components  consisteiit  The  ftmetion  span  uses  die  oompatiltility  nups 
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Giftazapi,  mapi^, 
local 

sparKcj)  <=  Agg(ci, C2)  where  Cl  smap2_i(Q2) 

hi 

og(8pan(c2))  4=  span(op2(c2)) 

CMi 


Hgure2.3:  Aggregate  Definition 


to  translate  betweoi  the  oompcment  and  die  data  aggregate.  The  toleration,  op,  on  the  data 
aggregate  can  thus  be  defined  using  ^lan  in  a  fonn  amenable  to  transfonnation.  Since  more 
dian  one  qieratkm  may  occur  on  die  lefdiand  side  of  an  eiqnession-procedure  definiticm, 
diere  may  be  soinecmtfusion  about  i)diichq>ention  is  being  defined.  Because  of  this,  the 
toleration  being  defined  are  underlined  to  distinguish  it  from  die  others.  This  is  but  tme 
example  of  a  definition  given  a  certain  set  of  translatitn  functions.  The  general  case  is 
treated  in  Section  6.1. 

The  Steps  of  Litegration.  The  essential  steps  forimplementingdata^pes  by  comptmcnts: 

1.  Spedly  the  overall  datar^  interface.  The  names  of  the  operations  are  listed  with 
their  signatures. 

2.  Definedieoamponentimplenimitatitms,eachafDdiichimplmnentssomesubsetoftlie 
overall  interface.  Collectively,  all  of  die  ctxnponents  implement  the  entire  interface. 

3.  Define  functions  dutt  translate  from  one  component  into  another  to  establish  the 
consistmicy  of  die  collection  of  data  rqnesmitations. 

4.  Choose  die  product  of  the  compmient  representations  as  an  expedient  rqiresentati<»L 

5.  Integrate  the  components  to  define  the  composite  datatype.  Eadi  operation  defined 
in  a  component  induces  a  conreqxxidmg  operation  on  die  aggregate  datatype.  Each 
aggregate  datatype  operation  is  defined  Qn  a  form  ammiable  to  transformation)  in 
terms  oi  the  component  where  die  qieration  was  defiired. 

Eianylf.  Suppose  we  are  given  two  components  diat  implement  different  buffer  oper- 
adoitt  and  a  relation  dutt  defines  what  it  means  for  diem  to  be  coosistent  The  operaticxis 
movn-rfgM  and  ahow^char  are  defined  in  die  first  componmit,  Bufi,  makabuf  is  defined 
in  die  second  component,  Bofi*  The  consistency  idation  is  defined  by  map^.  Using  the 
axioms  for  die  aggregate  ^lecificatiCTi  as  our  tanplate,  we  cwnbine  these  two  components 
into  a  composite  data  structure. 
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aiioaiprpji(mak8buO  «  makebufz 

tedompniiib)  mapf  projj^)  •=>  proJ,(makebuf)  maf^  projjCmakebul) 
asiiMiprpi,(move-rigtit(fr))  «  move-ilghtiOxoj,^)) 

«zioaiproj,0)  map?  pn^0)  >=»■  prpi,(mov8^ht(6))  map^  proh(move-right(6)) 
axi«iishow-char(6)  «  8how-chari(proji(6)) 

Using  an  algoridun  diat  preserves  die  properties  of  the  axioms*  an  aggregate  d^nititm  is 
produced  fircxn  die  axioms.  This  algorithm  is  oplained  in  Secticm  6.1.4. 

Stracture  Bu£ :  BUF  s  struct 
rtmctureBufi,  Bufa 

type  buf  a>  Buf  of  (int  x  ch*  x  ch*  x  ch*) 

local 

mapi^i(Buf2(/,r))  ^  Bufi(#/,/#r) 

8pan(Buf2(/,r))  <=  Bu£0»,  I, /,r)wll«Bu£i(p,0  =  map2_,(Buf2(/,r)) 

unspan(Bu£(p,/,/,r))  «=  Bufi({p  j  P2 },  { t  Ma }) 

^HKmBu£i(p2>t2)  «  map2_j(Bu£2(/,r)) 


makebuf  <=  8pan(makebu^ 

un8pan(mova-fiohl(ft))  <=  move-right,(unspan(6)) 
ahowr-charCA)  8ho«v-chari(unspan(6)) 

CMl 


Notice  how  the  definitions  for  makebuf,  move-right,  and  show-char  are  in  the  form  of  data 
transform  procedures  fnxn  die  tanplate  in  Hgure  2.3.  The  notati(m{vi  |  V2}usedindie 
definition  of  unspan  denotes  alternative  ways  of  ctwiputing  die  same  value.  It  is  necessary 
in  diis  case  to  preserve  die  coosiAency  between  the  data  structures  the  two  components 
diat  comprise  the  data  aggregate.  Sometimes  unspan  is  used  instead  of  span  decoding 
upon  ndiat  translatitm  functions  are  available. 

Using  tlw  llraittfornistion.  This  integration  process  is  useful  for  integrating  collections 
of  components  to  implement  datatypes.  A  detailed  example  is  shown  in  Section  3.1. 

Addinga  New  Component 

Yfe  adi^  die  ssrstem  by  introducing  a  new  component,  03,  which  d^nes  the  operation,  x. 
The  aggregate  qwd&atioo  for  die  new  systnn  is  defined  by  siqiplnnaiting  the  previous 
dt^nition  for  die  aggregate  qiedfication  widi  a  coUectum  of  axioms  defining  the  operations 
induced  from  die  new  component  The  first  axiom  defines  the  behavior  of  the  (yeraticHi  on 
the  aggregate  datatype  in  terms  of  die  new  comptment  The  fcdlowing  three  axioms  ensure 
thtt  after  q^yii^  die  operation,  all  of  the  components  are  kept  consistmt  The  last  two 
axioms  are  exieittiona  to  die  previously  d^ned  axioms  for  op.  They  misore  that  die  newly 
introduced  component  is  kqx  ctmsistait  after  qiplyii^  an  operation  in  the  existing  system. 
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CavcKopi,  mapi^j,  Xi,  mapj^, 
load 

un8pan(Agg2><j(c2,c3))  ^ 

{  mapi^Cca)  |  03  } 

8P»KAgg3x3(C2.C3))  <«= 

Agg'Cci,  cj,  C3)  o*«re  ci  «  mapi^iCcj) 
8paiy(Agg(ci,C2)) 

Agg'Cci,  ca,  C3)  i^ar«  C3 « fnap2_3(c2) 

in 

Unspan0i2xs(A992x3(C2>C3)))  ^ 

Xs(unspan(Agg2x3(C2,  C3))) 

X(span(Agg2x3(c2,C3))) 

8pan(xax3(c2,  C3)) 

Og^(8pan'(Agg(ci,C2)))  <= 
8pan'(op(Agg(ci,  ca))) 

end 


Figure  2.4:  Merging  with  die  Original  System 


asiiMipr(^0((agg))  =  )^<lproi3<agg)) 

«»*0«pnH2(agg)  nwpi  prpiiCagg)  •=»  profeWagg))  mart  prpj,(x(agg)) 
aztoniprahCagg)  mau  praji(agg)  ■=>  proi,(x(agg))  mam  prDj,(x(agg)) 
azknprohCagg)  ma(^  pncHaCagg)  >=>  prpb(x(agg))  map|  proj2(x(agg)) 

adomprolaCagg)  ma^  proji(agg)  =»  prpbWagg))  ma^  pr(^j(op(agg)) 
azhnnprojjCagg)  map|  prpjaCagg)  =►  proj3(op(agg))  mapf  proj2(op(agg)) 

There  is  some  flexibility  in  how  to  integrate  the  new  comptment  to  produce  die  aggregate 
defirdtum.  Here,  we  comdder  four  alternative  methods  of  compement  ad^itatuxL  Ttese 
definidems  all  satisfy  die  axioms.  Wt  have  the  choices  to  **mexge”  or  **ttanslate”  the 
new  cmnponent  with  die  ccnnponmits  in  die  original  system  or  with  the  data  aggregate 
implmnentation. 

Mergiiig  with  the  Orighud  System.  We  could  merge  die  new  componmit  widi  the  emn- 
ponrats  in  die  original  system  (see  Figure  2.4).  The  first  two  public  definidems  (after 
the  keyword  in)  incrementally  build  a  definitum  for  the  new  operation  (usit^  die  mediod 
introduced  in  Hguie  2.3).  Tbe  first  d^nititm  **8pans**  die  representation  frexn  the  new 
component  to  an  intermediate  aggregate  consisting  of  die  seomd  and  durd  compement, 
Aggjxs.  The  next  definition  **qians”  die  r^resentation  from  this  intermediate  aggregate  to 
die  new  data  aggregate  consisting  of  all  dneeccHnponmits.  'I\vo  steps  are  necessary  in  diis 
case  because  of  die  translation  functions  available.  Since  we  are  not  given  a  func^  diat 
translates  from  die  dtird  oomponent  to  die  first  compoorat  direedy.  we  must  first  merge  the 
diiid  component  with  the  second  componmit,  and  dien  widi  the  fast  compement  Qmipare 
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Ghwopi,  nwRi-.s 

load 

urwpaiXAggjCca))  -«=  mapi^jCci) 
span(Ag^(c2))  •<=  Agg(ci ,  ca)  where  ci  =  map^_^,(c2) 

tai 

unspan0fa(Agg2(c2)))  <=  )?j(unspan(Agg2(c2))) 
X(span(Agg2(c2)))  -e=  sparKxaCca)) 

end 


Figure  2  'nranslatmg  into  the  Oti^nal  System 


diese  two  definitions  with  die  definition  ofintegrating  tile  existing  Systran  in  Hgure  2.3.  The 
diagram  to  the  top-iij^  in  the  figure  illustrates  tiie  process.  The  labeled  nodes  represent 
the  compments  wdiich  are  connected  by  directed  arcs  tiuu  rqaesent  the  compatibility  mq>s. 
The  solid  boot  endoses  the  component  atoe  the  opraatkm  o£  interest  is  defined,  in  ^ 
case,  component  a  where  xa  is  defined.  Dashed  boxes  represent  the  derived  operatirais 
on  the  intennediatB  and  final  aggregate  (there  is  rate  for  each  of  the  two  definitions).  Ex¬ 
amine  them  starting  at  the  inner-most  box  and  proceeding  outward.  Rrst  X2x3  is  derived 
(correspondiog  to  the  first  definition)  and  tiien  X. 

We  also  add  the  last  definition  to  extraid  the  previous  definitions  for  the  opetatitms  in 
die  existing  system.  Wt  start  with  the  definition  oi  op  tinned  in  die  aggregate  craisisting 
of  Cl  and  C2  (solid  bmc  in  the  bottom-right  diagram);  ^n  we  derive  op' to  include  ca  (outer 
dashed  box). 

Thmslating  into  the  Origiiial  Systran.  An  alternative  to  merging  is  translating  the  new 
component  into  die  existing  system  (Hgure  2.5).  Only  the  operations  ttf  the  new  component 
need  to  be  defined,  since  die  radsting  Systran  does  not  change.  As  widi  merging,  the  two 
public  definitions  inctranentally  build  a  definitum  for  die  new  opexatioo.  The  first  definition 
’'plans’*  the  xqKesentatum  firom  die  new  compcment  to  die  existing  comprmrait,  radier  dian 
die  intennediate  aggregate  in  Hgure  2.4,  since  we  ate  translating  and  not  merging.  The 
next  definitkwi  “spans”  die  representatirai  from  the  second  oomponrait  to  die  data  aggregate 
of  the  radsting  Systran.  There  is  no  diirddefiniticm,  as  was  the  case  in  merging,  because  die 
radriing  pperations  do  not  have  to  be  modified  since  die  aggregate  lepresraitation  remains 
die  same. 


Mcrgbif  with  the  toqrtranentatioo.  Radier  than  starting  with  die  original  definiticxis 
of  die  radsting  synem,  at  times  it  may  be  beneficial  to  treat  die  imptementation  of  the 
aggr^ate  as  a  component,  and  merge  the  aggregate  and  new  component  direcdy.  Recall 
diat  die  process  of  (ditaining  an  implenmntation  from  the  aggregate  definition  involves 
trying  tnsutaaaetioDS  to  the  definition  to  obtain  a  prototype,  and  dien  qiedalizing  the 
prototype  to  obtain  an  imptenentation.  This  qiecialiation  process  can  be  diaracterized  as 
a  translation  function,  map^,  diat  maps  prototypes  into  implemraitations.  Fbr  die  sake 
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Qvckxs, 

load 

un8pan(Aggj,x3(i2.c3))  <=  {map^^sdi)  i  cs} 

8pan(Agg*xs(i2. cs))  <=  Agg^^^xjUi .  12, cs)  when  U  «  map^_i,(i2) 
8pan^(Agg(ii,i2))  <=  Agg'(ii,i2,C3)wlioroc3«map4_3(i2) 
tai 

w»panQt^x3(Aggi,x3(i2,c3)))  <=  xa(un8pan(Agg^^3(i2. 03))) 
X(8pan(Agg4x3(i2,C3)))  <=  8pan(X<.x3(i2,  C3)) 

gg^(8pan'(Agg(i,,i2)))  8pan'(op(Agg(ii,  ±2))) 

cwl 

Hgure  2.6:  Nfetging  with  the  Implemoitatitm 


of  concreteiiess,  let  us  say  diat  die  spedalizatun  process  takes  the  two  compcuients  of  the 
prototype  aggregate,  and  specializes  the  first  ctunponent  and  keeps  the  sec(^  component 
intact 


n™ap^Agg(ci,C2))  a  AggKf(ci),  C2) 

Pexfai^  we  can  define  a  translation  fimctioo,  map^_^,  for  the  relationship  between 
the  two  comptments  in  die  implemmitatimi  in  terms  (tf  lite  compatibility  mq>,  map2_i 
(which  cjqiresses  die  relationship  between  the  components  in  die  prototype),  and  the  gans- 
ladon  ftmetioo,  map^  (ududi  etqnesses  the  relationship  between  the  prmotype  and  the 
implementation).  Then,  if  we  define  the  relationship  between  the  new  comptmoat  and  the 
implmnentadon  as  the  translation  function,  mapi,_c,,  we  (ditainadefinitioo  for  die  adapted 
system  (Figure  2.6).  Notice  die  similarities  bc^vramidiisdefinitimi  and  die  previous  one  in 
Hgure  2.4.  We  have  substituted  for  map^i  ^triuch  **pr(miotes”  the  qtedalizatimi 

filter  (i.e.,  f  in  map,.^)  to  die  time  the  integration  is  performed  so  that  we  may  be  ^ared 
doing  extra  wodc  ody  to  elimtnatr  it  later  in  die  derivatka. 

We  are  able  to  treat  die  implonentatitm  of  die  aggregate  as  a  compcmmit  only  under 
certain  oonditimisdiough.  When  diere  are  no  interdqiendaicies  among  die  aggregate,  then 
it  is  siii^le  to  treat  die  aggregate  as  a  componmit,  since  diere  are  no  ^internal”  translaticm 
functions  to  be  concerned  with.  When  the  translatum  foncticHis  are  many-to-one,  it  may 
not  always  be  possible. 

TYniMlating  Into  the  foqilcnientatioa.  An  alternative  to  merging  is  translating  the  new 
conqwnent  into  die  existing  system  (Hgure  2.7).  Only  die  qieratimis  of  the  new  component 
need  to  be  defined,  sinoe  die  existing  system  does  not  change.  The  sanm  compaxisoa  made 
between  merging  and  translating  on  the  original  system  i^Ues  to  merging  and  translating 
on  die  implmnmitation. 

The  Steps  oi  AdsptatiQii.  Adqxatkm,  adding  a  new  cmnponent,  is  similar  to  die  orig¬ 
inal  problem  of  derigning  and  implementing  die  initial  sysinn,  since  bodi  tasks  can  be 
conoqicnalized  as  the  task  of  integrating  compcmoits. 
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GhfKXs,  map^^j 
local 

un8pan(agg<,(ia))  <=  map^^aa) 
apanCAgg^aa))  >c=  Aggi,x4(ii,  ia)wfcmii -map^^da) 
fai 

un8pan0s^,(Agg<,(ia)))  <=  XsCunspaiKAgg^da))) 
XCaparKAgg^da)))  «=  apanOtfcda)) 

Hgnre  2.7:  Tnuislating  into  Ac  bnpleinentatkn 


The  stq»  for  adiqiting  a  datatype  by  adding  a  new  comptnent: 

1.  Extrad  the  ovenll  datatype  intoface.  The  names  of  the  new  qperadons  and  type 
infonnadon  are  added  to  the  signatme. 

2.  Define  die  oomponait  implemmitation,  using  a  data  iqnesoitation  most  suitable  for 
die  operations. 

3.  Write  a  single  translation  fimctitn  between  this  ocnnpoaent  and  anodier  in  the  existing 
system. 

4.  Choose  die  product  of  die  new  comptment  rqxesratatkm  and  ctxnponent  rqnesen- 
tations  of  the  existing  system  as  an  expedient  rqpresmtation.  Or,  as  an  alternative 
choice,  keep  die  representation  of  the  existing  system. 

5.  Integrate  die  new  component  by  adding  new  definitums  for  die  operaticmstMned  in 
die  new  compooent,  and  by  extending  die  definitions  for  die  qieraticHis  in  the  existing 
system  to  iqidate  the  new  component  (If  die  representation  of  die  existing  system  is 
chosen,  dien  die  operations  of  the  existing  system  do  not  have  to  be  redefined.)  Each 
aggregate  datatype  operatkm  can  be  defined  Qn  a  form  amenable  to  transformation) 
in  terms  of  die  component  D^iere  die  qieratum  was  defined. 

Example.  Wt  use  the  merging  with  the  orfgjna/tysremqproadi  in  diis  example.  Recall 
that  die  buffer  system  in  the  example  of  die  laevious  secticm  was  defined  using  aximns 
diatqiecified  how  to  integrate  die  origiiial  two  cmnponents.  This  definiticm  is  miriched  to 
inclnde  a  new  comptment  for  pages  by  adding  dwse  axioms: 

aBiiwp(rp|^(fbrward-paoe(fr))  «  Buf,.forward-paoo(pro^(6)) 

ailaaiproii(b)  marf  proj^b)  -o  prpi,(lbrward-paoe(fr))  map?  prp|^(brwaRH)aoe(»)) 
•adampn^ib)  map;  prp|p(fr)  prejjClbrward-paoeCb))  map;  prai^(1brward-page(b)) 

The  first  axiom  qiedfies  die  behavior  of  die  forward  i»ge  operation  on  die  data  aggregate 
in  terms  of  the  page  component  where  it  was  defined.  The  ranaining  axioms  misure  diat 
die  ssfstem  remains  consistrat  after  the  (qieration  is  performed. 
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Additionally,  tfie  axioms  for  tiiBoriyiudoperaiioos  mast  be  extended  to  ensure  conns- 
tcacyoftfaenewcanpooeativfaenanddoperatiooisqjplied.  For  example,  die  axioms  for 
move-right  would  be  extended  widi, 

aiioaipraj,(6)  map^  proj^(6)  >0  prai,(move-right(d))  map|[  pro^(move-right(6)). 

Li  order  to  produce  an  aggregate  definition,  a  compatibility  nuQ)  diat  reflects  map^  must  be 
provided.  In  the  compatibility  miqidiat  follows,  die  new  page  component  is  comiwtedfirom 
die  original  Buf  1  component  using  the  auxiliaiy  functions  npeges  to  count  the  number  of 
pages  in  die  sequence  ofcharacters  to  die  left  of  die  cursor  (v^ieresM]  isdiesubsequau» 
of  5  from  the  beginning  to  0,  and  chars2paoes  to  parse  die  sequence  of  characters  into  a 
sequence  of  pages. 

mapj^(Bu£i(p.t))  BufjXnpagesCi  t-(p  -  l)i ),  char82page8(()) 

We  otoin  a  new  definition  for  each  pa^  operation  in  die  new  data  aggregate  (using  an 
extension  of  the  algorithm  that  integrated  the  original  system  in  the  previous  mcample).  For 
example,  die  definition  for  forward-page  fcdlows. 

locai 

unspan(Bu£ix^,<,/ri,<p))  <=  {  map,^(Bu£j(p,  0)  I  Bu£^i,  9») } 

un8pan'(Btt£'(p,r,/,r,^,V))  <=  Bu£ixf({p  I  P2  ),  { r  I  n  },  pi,  tp) 

whore  Ba£i(;n,r:;0  ■  >Bap2_j(Bu£2(/, /)) 

ia 

unspanQiorwafo-paga.  „^(h))  foiwariH»Qe/un8pan(fr)) 

unspan*(liorward-paBe(h))  <=  fbrward-paoajx/unspan'C^)) 

Notice  how  dus  take  two  steps.  First  we  obtain  a  definition  for  forward-page  for  the 
intermediate  aggregate  Buf  and  tboi  for  die  new  aggregate  consisting  of  die  product  of 
all  die  components. 

We  also  obtain  a  new  definition  foreach  operation  of  die  existing  compcmmits  in  die  new 
aggregate.  For  example,  die  move-right  operation  must  be  extended  to  d^netbeoperatiem 
on  die  new  aggregate  that  includes  die  new  page  componem  in  terms  ctf  the  (dd  aggregate. 
This  is  done  by  simply  adding  a  new  definition. 

local 

Span(Buf(p,l,/,r))  «=  Bu£'(p,  t,  I,  r,  pi,  tp) 

where  Bu£,(pr,tp)  -  map,_^(Bu£j(p,  1)) 

hi 

roove-rlghf(man(d))  <=  8pan(move-right(h)) 


Notice  how  die  definitions  for  forward-page  and  move-rf{^  compare  with  the  tnnplate 
in  R^ne  2.4.  We  may  substitute  spvi  for  un^ian  or  vice-vorsa  depmiding  mi  what 
compatildlitynuqis  are  available. 
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llrii^flwlhuHibrantion.  This  adi^Matioa  process  is  oiefd  for  adqytingdat^ypes  and 
intipdiiciiignew  fanctionality.  A  detailed  example  is  shoiwn  in  Section  32. 

2.L2  Larger-Scale  Systems 

This  next  example  of  using  die  text  huffier  as  part  of  a  diqday  editor  suggests  a  paradigm  of 
system  ingdemeotation  by  modules  \^iere  we  use  transformation  techniques  to  get  better 
performance  tiian  simply  reusing  code.  The  building  blocks  for  this  paradigm  include 
otgects  and  modules  (see  [33]  and  [90]  and  otiiers,  [9],  [58],  [87]).  Laiger-scale  systems 
can  be  built  using  modules  hieraichies  (U.,  modules  diat  import  otiier  modules).  The 
module  transformation  system  provides  a  way  to  manipulate  diese  building  blocks  and  to 
dumge  tile  oohesivmiess  and  the  couplings  oi  tiie  modules.  Initial  eaqierimice  suggests 
that  tedmiques  demonstrated  for  the  integration  of  cmnponents  are  applicable  to  module 
systems  as  well 

Adai^ii^  Module  bterfaces 

New  modules  can  be  defined  in  terms  of  existing  modules  to  adqit  abstract  interfaces. 
This  is  accomplished  by  defining  a  module  that  imports  an  masting  module,  using  some 
of  tile  existing  functions,  and  periups  adding  additional  functions.  This  is  diffierent  from 
adapotion  1^  adding  a  new  oompooent  because  in  addition  to  adding  new  functions,  we 
can  ddete  or  modify  tiiem  as  well 

We  are  aUe  to  baOd  a  system  using  a  hierardiy  of  modules  vdiere  data  amcmg  die 
modules  may  be  shared.  Operations  from  tiie  imported  module  can  be ’^propagated’*  into 
the  inqxvting  module.  Wc  say  udutt  is  meant  by  extending  a  module  by  using  axioms 
to  define  a  specification.  The  singlle  axiom  below  defines  tiie  behavior  of  tiie  propagated 
operation  op^  in  tile  importing  module  in  tenns  of  die  imported  module  operation  op. 

mkaaprqKap'fa))  -  ap(prpKa)) 

Now  we  define  how  tiris^iecification  is  ingitanoited.  Given  die  inqiorted  module  and 
a  fonction  nuqiping  between  the  data  in  the  imported  and  importing  nradule,  mapj_MH,  new 
definitions  for  die  operations  are  defined. 

locri 

span(c)  aggCe'.r) 

whwtc'-map^(c) 

aadr«/(c) 

la 

gg^(apan(e))  <=  apanfopCc)) 

The  importing  module,  Af ,  starts  with  die  imported  module,  M,  and  adds  somedung  mctia, 
perhaps  a  new  data  field  or  additional  operations.  In  tins  exanqde  Af  uses  the  data  finom 
Af  and  adds  a  new  field  tiiat  is  computed  using  /.  The  function  span  uses  die  nupping 
ftmetion  to  tmslaiB  between  A#  and  Af  so  diat  op' is  defined  using  span  as  a  data  transform 
procedure. 
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The  Slept  of  Adaptitfioii.  llie  steps  for  adq>dng  module  inteifBoesii^g  module  exten- 
sfoos  is  similar  to  the  process  for  integrating  compoomts: 

1.  Specify  die  module  interfoce.  The  names  of  the  qieraticms  are  listed  widi  dieir 
signatures. 

2.  Definedieimplementatioa.  Thisisdoiiebyq^lyingdiissamemedKxkdogytodefine 
a  new  module,  or  by  using  or  adapting  a  module  firom  a  reusable  library  of  software 
components. 

3.  Choose  a  represcjitation,  possibly  including  odier  modules  as  substructures,  and 
defining  the  data  rqnesentation  in  terms  of  die  datatypes  contained  in  these  modules. 

4.  Define  the  implementation  in  terms  of  die  substructures.  There  may  be  a  correspcMi- 
dence(egn  data  invariance)  betwemi:  (1)  two  imported  modules,  or  (2)  a  module  and 
the  module  it  tnqiorts.  This  correspondence  is  eaquessed  as  a  translaticHi  function. 

Eiaiiii^  We  define  a  multfyle-buffier  diqilay-editor  using  a  module  that  defines  die 
screen  and  a  module  diat  defines  **geneiic**  association  list  (Aiist)  operations  to  manage 
die  ttaie  of  the  bufifias.  The  di^h^  editor  inherits  die  state  from  the  Aiist  module  and 
adds  somedung  more,  the  state  of  the  screen.  Each  operatitm  in  die  Aiist  module  induces 
a  corraspontog  operation  in  die  ttapliyediton 

The  Aiist  module  has  an  operation  select  fior  selecting  data  in  a  list  given  a  key.  We 
use  it  to  look  iqp  a  buffer  otgea  given  its  mane.  This  new  buffer  qperatitm  select-buff  er 
satisfies  the  axiom: 

aiioaiproKssiect-buflerO>.a))  «  selectCw,  proRa)) 

An  Aiist  is  rqpteseoted  as  a  list  of  pairs  (of  keys  and  data),  where  die  beginning  of  die  list 
is  cadied.  The  lelecied  data  is  moved  to  the  begiiming  of  die  list  in  this  cached  posititXL 
The  relationship  between  die  Aiist  module  and  die  dufday-editar  module,  Ded-Mbsw, 
diat  includes  it  can  be  eaqaessed  as  a  translation  function. 

spsn(Aiist(r,l,4))  D«d-Mbsii(aii8t(r,  k,  4)>  r) 

whav8'*poi(^4),  r>(ft^to-screen(o',  4) 

Notice  how  Ded-Mbsw  uses  die  state  ftom  die  Aiist  module  and  adds  the  state  of  die 
screen,  s.  The  screen  is  computed  ftom  information  contained  in  die  Aiist  sudi  as  die 
current  buffer  and  origin.  The  operations  for  die  multqile-boffer  display-editor  are  then 
defined  in  terms  of  die  Aiist  operations. 

aalect-tmller<s.aDanfsli  es  spwXteiecRs,  a)) 

The  operations  defined  in  the  Aiist  module  are  then  reimplearented  in  die  context  of 
dtetHspfagr-ediior  module.  For  examide,  instead  of  Miect-bultar  having  to  call  select,  a  new 
definition  for  eeloct-buller  is  derived  that  operates  on  die  state  of  die  buffers  direedy.  Not 
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only  does  tfds  ioGxeaae  pofionnaDoe  dSminatmg  die  invocatioD  of  select,  but  it  enables 
die  possibiHty  erf  fnrdier  transfionnatioos  that  cookl  qiecialize  the  screoi  in  die  coniQct  of 
die  bnfier  state  (eg.^  inoememal  iqidatB). 

Keqi  in  mind  diatdiisexanude  demonstrates  a  paiticiilar  set  of  design  decisions.  The 
software  devdoper  has  in  many  cases,  a  range  of  alternatives  to  dioose  from  to  produce  a 
varies  of  solutions. 

Using  the  Tlransftarmation.  lldstransfocmatiooivofvidesacontrdledmedioddogy  for 
propagating  change  and  increasing  the  efBdency  of  modnk  systems  by  tighter  coupling. 
See  Chqieer  4  for  a  detailed  example. 


2J2  Data  lyansformation 

Early  data  transformation  methods  focused  on  die  relationfthip  betweai  abstract  programs 
and  dieir  inqdementations.  Hoare  [46]  presented  a  method  for  proving  die  conectittss  of  a 
data  iqxesentatian  fiv  an  abstract  program. 

Oivea  an  distract  program  f  on  an  abstract  domain  D,  die  concrete  program  f  on  die 
ooncieie  domain  O' is  a  correct  imidementation  of  f  if  die  following  diagram  commutes, 
f 

D - -  D 


Abe 


Abe 


That  is  (where  is  an  element  of  domain  DO* 
fCAfaa(rf»  -  Abe(f(40). 


(1) 


The  abstraction  fimetioo  Abe  nups  the  concrete  items  into  die  abstract  objects  tdudi  diey 
lepresem.  This  approadihu  been  adopted  by  VDM  [7]  vdiere  Abe  is  called  a  **retrieve*’ 

f^ingtinw, 

An  atteraadve  approach  is  to  derive  die  concrete  tepresenration  using  program  trans- 
fbrmation  [1^  radier  dian  invent  die  concrete  represrjitation  and  dien  prove  it  correct 
The  representation  fimedon  Rep  nuys  the  abstract  object  into  a  concrete  rgaesentation. 
This  Erection  is  chosen  to  Baqdify  die  derivation  but  is  only  applicable  vdien  an  injeedve 
rqpresentmion  function  can  be  defbwd  (dxmgh  it  does  not  necessarily  have  to  be  unique), 
f 

D  .  D 


|Rnp 

D' - 


f 


|Rep 

1/ 


fChepm  •  WiPCW)) 


(2) 
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White  the  above  equation  may  ixx  immediatdy  suggest  an  inqdeinaitatioii,  in  many  cases 
tnmsfotmatioos  can  be  qiplied  to  otain  an  executable  definitinn  for  f.  Datiington  [17] 
dioiws  bow  a  concrete  progiam  is  derived  from  an  abstract  program  using  progiam  trans¬ 
formations,  thereby  eiuRBing  diat  the  imptementadon  is  conect;  given  an  abstract  program 

f  on  an  abstract  domain  D  Old  a  target  domain  D',  die  concrme  program  f  and  die  nuonung 

Rep  can  be  derived.  Of  course  it  is  not  enon^  to  transform  only  one  function  —  all 
fnrictions  that  operate  on  objects  in  the  domain  must  be  transform^  This  can  be  more 
easily  aooonqdtehed  by  using  datatypes  to  groiq)  die  functions  that  operate  on  an  otgect 

Not  orily  can  transformations  be  rqifdted  to  gri  firem  abstract  to  concrete  programs,  diey 
can  also  be  qiplied  to  concrete  programs  (or  datatypes)  dwmadves.  [91]  develops 
tins  idea  by  consideting  the  intenelarionriiips  along  data  padis  in  programs  and  outlining  a 
set  of  informally  described  operations  on  datatypes.  These  include  operations  for  delaying 
or  advancing  computation  and  operations  for  chimpng  type  signatures  based  on  die  “dieory 
operations**  of  BurstaU  and  Oognen  [13]. 

Iptring  and  Scheriis  [49, 76]  develop  and  generaliaediese  ideas  even  furdier  to  obtain  a 
framework  that  permits  programmers  to  take  general-purpose  abstract  datatype  definitkms 
(vriiidi  might  Gonoe  from  a  reuse  library)  and,  using  type  transformations,  obtain  types 
taOosed  to  the  qipHcation.  Described  in  terms  of  the  above  diagram,  a  given  datm^ 
D  widi  its  asaociatfid  operations,  for  examine,  f,  can  be  adqited  to  yield  die  qiecialized 
datatype  D'  widi  its  associated  operations,  f .  The  miqiping  Rep  is  also  derived  using  die 
context  m  vritidi  the  datatype  qipears. 

23  Module  Transformation  Rules 

Sdieilis  [7<0  uses  four  strategies  called  wcorporaUt  release^  expose^  and  sMft  for  ttans> 
forming  abstract  interfmes  and  data  rqxesentations.  These  are  techniques  for  adjusting 
interfmes  and  data  reprcjentariom  widnn  a  given  sjfstem.  The  sMit  strategy  is  a  data- 
itpresentttiontransforination  that  has  a  direct  effect  on  program  performance.  Dqpending 
on  the  relative  frequencies  of  operations,  computation  is  nuived  between  generation  tinre 
(where  biformation  can  be  cadied)  and  access  tiine  (where  information  can  be  computed  on 
demand).  The  incorporate  and  release  strategies  transform  abstract  interfmes  by  moving 
abstraction  boundaries  {ijt.,  internal  program  inierfioes  as  defined  by  type  signatures)  to 
fimOilaie  inqprovements  in  die  effidoicy  of  the  type  representations.  Tlte  rsqiose  strategy 
transforms  bodi  data  representation  and  abstract  interfiles.  The  internal  structure  of  data 
objects  is  revealed,  moving  die  abstraction  boundary  of  die  type  **inward,**  creating  new 
abstract  type  names  to  move  from  more  abstract  rqireseatations  to  more  concrete  tqnesen- 
An  examide  ofthe  transformation  <rf  a  data  representation  is  givwi  in  Section  3.13 
(widi  details  in  Appendix  Q. 

The  module  transformation  rules  described  in  dds  section  start  widi  Sdwriis*  frame¬ 
work.  Theteteniionistoluiveasmancmioiiicalsetoftnuisformatiaissoppteinentedwidi 
knoadet^  about  die  domain  of  die  data  structure  that  are  used  to  simplify  die  datatype, 
aril  of  dm  following  sirtisections  describes  a  modnte  transformation  rule  and  indnd^ 
mi  informal  deaerfydon  of  die  transformation  mediod,  an  example,  and  a  pointer  to  how 
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die  mediod  is  used  in  Ae  etdtor  exanqik.  The  infonnal  description  and  exanqile  riiow 
die  Old  lesnlt  of  the  tnmsfonnation  ttrategy,  bat  noc  die  intennediaie  stqis.  The  intent  is 
to  pseseot  tti  overview  of  die  transfonnations  to  qinddy  leadi  Section  2.4  where  they  are 
used  in  constructing  software  systons.  EMfiemit  langnages  are  used  in  the  exanqi^  to 
demonstrate  diat  dm  transfonnations  are  not  restricted  to  a  given  langnage  hot  to  languages 
duastpport  module  systems  in  general  After  die  editor  example  is  presented,  we  return  to 
diese  trmsftxmationmediodsia  Ch^Mer  6  where  we  see  die  steps  involved  in  qjplying  die 
transfiirniatton  and  a  more  formal  definition. 

When  first  reading  tins  section,  it  is  sufficient  to  examine  die  introductory  prose,  die 
example,  and  the  pomter  to  how  the  mediod  is  used  in  die  extended  example.  Aiterieading 
die  extended  example,  die  reader  may  wish  to  remm  to  diis  section  to  look  at  die  descriptiCTis 
to  leam  more  of  die  details. 

Notation  and  NandiigConvaitioiis.  Theinteifaoeof  die  datatype  is  rqnesaited  by  die 
type  name  and  the  signatnies  of  die  q[)entions.  Here  is  a  template,  nhere  die  italicized 
variables  are  to  be  filled  in. 


{/:  ty 


The  interface  of  die  datatype  dcoiudsts  of  die  functions  (iqiresented  by)  /  widi  die  type  r. 
One  or  more  instances  of  a  pattern  is  dnioted  using  {...}*. 

Theimplemcntatiooofdiedata^peisteigesaitedlydietypename,diedatarq«esen- 
tation  and  die  implementations  of  die  operations. 


■•pn41sa 

^{/(V)  <=  by 


The  inqilemeatation  of  dm  datatype  d  consists  of  die  data  iqaesentation  a,  and  die  imple¬ 
mentations  of  die  ftmctions/  w^  formal  parameters  v”,  and  bodies  b.  Function  definition 
is  denoted  by  When  dealing  widi  abstract  datatypes  (as  opposed  to  modules).  Rep  and 
Ate  are  used  to  manage  abttraction  boundaries  as  in  dre  original  ML  [35].  Rep  reveals 
dieandertyiitgdatastmctnreof  an  abstraction.  Ate  creates  an  abstractioiL  Repqipearing 
on  the  ri|ddfc*ed  side  of  a  procedure  definition  has  die  same  efBpct  as  Abe  ^ipearingCTi  die 
lefdmd  side,  revealing  the  underiying  data  structure  of  an  abstraction. 

A  rcpresentsrive  selection  of  die  operations  are  rimwn  in  die  descrqitions.  Fbrour 
purposes,  foe  operatioM  are  cat^orized  in  terms  of  triiedier  di^  produce  an  instance  of 
die  tn>6,opetare  on  die  9pe,  or  reveal  some  information  about  tte  type.  These  are  called 
generaiori,  extenrions,  imd  obeervers,  udtich  are  givea  foe  names,  ge^  ote  The 
iBipienieiiiiMOB  or  toe  opermoB  is  signiticfl  as  a  pattern,  using  &,  c,  or  u  tor  tne  tmee 
lipresrsilaiive  operadons  axKAbeCe))  ^  AbaCBCa))).  Alfoou^  diese  categories 
correspond  to  ones  med  in  defining  algforaic  qiedficauions  of  abstract  datatypes, 
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die  xeason  to  use  diem  here  is  to  demmistrate  the  qiplicabOi^  of  the  transfonnadonal 
technupies. 

The  typewriter  font  is  used  for  datatype  names,  sans-serif  font  for  function  names, 
and  Aafics  for  variable  names.  Ihe  product  type  constructor  x  bimls  more  dshdy  than  the 
function  type  constructor 


23.1  IVanslate 

Uang  die  mutsUtU  transformation,  die  software  devdoper  can  change  the  rqpresentadmi 
of  a  datatype  ttidAir  move  oonqnitation  along  die  data  padis  of  a  prognun.  Thischangein 
representations  is  eqnessed  tty  a  function  that  maps  from  the  original  rqnesaitatum  into 
the  new  one.  The  transformation  provides  a  mechanical  means  (widi  guidance  from  the 
user)  to  reimplement  the  operations  of  diis  datatype  on  die  alternative  data  representation. 
The  meaning  of  die  abstract  datatype,  however,  remains  die  same. 

Emnple.  A  anqilebiiflGcr  datatype  has  operations  to  create  a  new  instance  of  the  buffer, 
insert  a  characiei;  and  diow  the  character  at  die  point  of  editing.  Standard  ML  [60]  notatiem 
is  used  to  rqnesent  this  datatype;  die  al»tract  interfisce  is  denoted  by  an  ML  signature. 


StpwmnBurssig 

typebaf 

relmakabuf:  buf 
valinMrt:  ch^buf  — >bu£ 
wJ show-char;  bu£ -  > ch 


The  imptementation  of  die  datatype  is  dmxited  by  an  ML  structure.  A  buffer  widi  a  data 
ttructure  that  lepreaoats  die  buffer  as  a  pair  of  sequences  of  diaractetsC#  isqipend). 


Strachars  But;  HOT  g  struct 

type  buf  a  Buf  of  (ch  List  *  ch  List) 

ndmakabuf  ■  Buf(nfl,  ni) 
taiinssrKc,Buf(/,r))  a  Buf(/#a8Kc),  r) 
Aniahow-chaKBuf(/,r))  a 


and  a  function  diat  translates  diis  data  rqneseatation  into  a  new  one  consisting  of  an  index 
and  a  sequence  of  duBBCters, 

apanosufd,/))  a  Buf'(isn(0,/#«') 

are  trniafonned  (after  several  transformation  siqis).  The  new  data  structure  represoits  the 
bifffor  as  an  index  to  die  point  of  editing  and  text 
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Struetmn  Buf' :  buf  sftracl 

Igppebuf  ■  Buf  ei  (int  *  ch  List) 
valmakabuf  •  Buf  (0,  nil) 

tai  in8ert(c,Buf(p,0)  >  Buf<p<t- 1, 8iJb6eq(t,0,p  - 1)  #  HsKc)  #  8ub6eq(x,p, len(0)) 
ftni  8hQw-ch«(Bu£^,0)  «  nth-ltein(i,  ^  - 1) 


A  <fiffeiait  example  widi  tbe  steps  included  is  shown  in  Appendix  C 

Dcacri^ioii.  ^  iUustiate  the  transfonnatkm  process  widi  a  gmienl  datatype.  The  ab¬ 
stract  interface  for  die  general  datatype,  Dtype,  containing  a  rqnesentadve  collection  of 
operations  fcdlows. 

iBlarflMeDtypsis 
gen :  Dtype 
ext :  Dtype  -» Dtype 
Obe :  Dtype  0 


The  operatians  are  defined  on  a  datatype  widi  representation  a.  Fdrmcample,  ext  takes  an 
itiatence  of  die  datatype  as  an  argument,  reveals  die  underiying  data  rqpresentadon  ci  die 
abstraction  (rqsesented  tty  a),  petforms  some  operations  on  it  (represoited  by  the  pattern 
£),  before  returning  the  result  as  a  new  abstractkxL 


Rapaotypeiia 

with 

gen  <=  Ab6(G) 
extCAbeCa))  <=  Abs(E(a)) 
ob6(Aba(a))  <Ka) 


The  fhncdon  span  diat  mqis  die  given  datatype  into  die  new  lepresentatum  is  provided 
below.  The  translation  of  die  data  rqneaentation  is  performed  by  5.  The  new  abstraction 
boundary.  Ate',  is  primed  to  distingnidi  it  firem  die  old,  but  diey  serve  die  same  imtpose, 
dmt  is,  to  ensure  dutt  the  underlying  data  rgnesentation  remains  hidden  outside  of  die  type. 
The  apwi  function  is  qiedal  tli^  since  it  is  can  manqmlate  these  abstraction  boundaries. 

5:  a-*ar' 

ap«i(Abs(a))  Aba'(S(e)) 

^Pldyh^  die  translate  transformation  produces  new  implementations  of  the  operations 
defined  on  the  tfaua  rqaesentation  o'.  The  stqis  are  shown  in  Hpne  2.8.  Topically,  the 
transformation  proceeds  where:  (1)  die  bodies  of  die  old  operation  and  span  fonctkm 
SR  expanded;  (2)  domain  knowle^  about  die  data  rqaesentation  is  apf^ed  to  simplify 
die  boify;  (3)  an  insi^  step  is  appUed  to  'hiidge*'  die  (dd  and  new  representarionr,  (4) 
■***«*ftwi  sfoqdiftcatian  aiqis  are  qifdied;  and  (5)  die  tpea  function  is  abstracted  firom  die 
bo^  of  the  operation.  More  information  is  proviM  in  Section  6.2.1. 


23.  ModuUTransformaHonRuUs 


27 


f(span(A))  <=  sparKfW) 
f(span(A))  <=  S(m)) 
f(8parKA))  <=  «(A) 
f(8pan(A)) 

f(8pan(A))  <=  F'(S(A)) 
f  (8pan(A))  c  F'CspanCA)) 
f(A)  <=  m 


Hgure  2.8:  Transfonnation  Steps 


ScpB  Dtype  is  o' 
wUh 

gen  <=  Abe'CGO 
exl(Ab6'(a))  Nx'(P{a)) 
ob8(Abe'(a))  •«=  0'(a) 

CMi 


Thus,  given  the  initial  data^pe,  a  functk»  that  mq)s  die  (dd  iqnesaitati(»  into  die  new 
lepresentatun,  and  some  indglit  from  the  software  devdk^ier  to  guide  the  transfotmadcm, 
the  new  datatype  is  prodnoed.  The  datatype  consists  of  the  new  implonaitadmis  of  the 
opentkxis,  lepresoited  by  (?',  f',  O',  that  operate  on  die  new  represratatimL 

Uiiiig  tbe  TVanallorinatioii.  The  translate  transfonnation  is  used  for  optimizadcm  or 
integtadoo  and  implementation.  Used  as  an  ahenuoive  to  computation  can  be  moved 
along  data  paths  to  increase  die  efficiency  of  die  program.  Fte  example,  if  a  data  structure 
is  accessed  ftequendy  but  modified  inftequendy,  dim  die  program  may  be  made  more 
efficient  by  shifting  die  computation  on  die  data  structure  ftom  vdim  it  is  accessed  to  whmi 
itis modified.  Uaedlodiangedietqaesentationofadatatype,acdlecticmaf'*views”can 
be  integrated,  or  a  hig^-level  datat^  dilution  can  be  implemented  in  a  more  cmurete 
domaiiL  For  examide,  dus  transfannadon  is  an  important  step  in  implemrating  datatypes 
by  components  and  is  used  in  deriving  an  aggregate  data  structure  for  a  text  buffn  in 
Section  3.13. 

233L  Shift 

Using  die  transfonnation,  computadon  is  moved  along  the  data  padis  of  a  program  to 
increase  die  efficiency  of  die  program  (eg.,  moving  computation  on  a  data  structure  from 
nhea  it  is  accessed  to  irfien  it  is  generate^.  This  may  change  die  data  rqnesoitadtm  of  a 
dttatype  but  the  meaning  the  abstract  dmatype  remains  the  same. 

Rsaaiplt.  Hereisanexanqjdeofthetrsnsfanaadonofadatareiaesentation.  Thccompu- 
tation  of  the  kngdi  of  a  sequence  is  shified  from  access  dme  to  oeadon  time  using  die 
ifiid  transformation.  The  dao^pe  for  die  natural  numben  contains  die  operations  zmo  and 
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adcione.  An  additiraalopenaun,  count,  for  converting  a  natural  number  into  an  integer  is 
added. 

ibie,  die  Qu  [S4]  language  is  used  fts'  tte  example.  The  abstract  interface  and 
implementation  are  defined  together  in  a  On  cluster.  The  k^wordcvt  denotes  the  abstract 
data^pe  being  defined.  C^ieraticms  defined  <m  a  type  are  referenced  typeSop,  for  example, 
the  cons  operadmi  on  lists  is  denoted  listScons. 

Nde£«  Amcris 

zero,  add-one,  count; 

rep  a  int  List; 

zero  >  procO  rcturas  (crt); 

retum(li8t$ni0: 
cad  zero; 

add-one  «  proc(j :  art)  retoms  (art); 

retum(li8t$oon8(l, «)); 
end  add-one; 

count «  proG(f :  art)  retams  (int); 

retum0ist$iength(5)); 
cad  count; 

TherepreaentatKmchosenisasequCTceof  Ts.  Zero  is  rqiresented  by  die  empty  sequence, 
adding  cue  by  concatenating  1  cmto  die  sequemx,  and  the  count  is  obtained  by  taking  the 
length.  If  cotmt  is  accessed  finqumidy,  dien  the  ctxnputadcm  of  counting  the  number  of 
elements  in  the  sequence  may  be  shifted  to  creadcHi  time  in  the  generator  functions  zero 
and  add-one. 

After  several  transfonnaticm  steps  (which  have  been  omitted  for  the  sake  of  brevity), 
the  fdlowing  is  obtained: 


Ndttfa  darter  ii 

zero,  add-one,  count; 
rep  aint; 

zero  a  procO  retarai  (at); 

retum((Q; 
cod  zero; 

add-one  a  proc(n :  at)  returae  (at); 

Srani-l; 

retumOi); 
cod  add-one; 

OOuntaprocOi:  at)  ictaiBS  (int); 

retumOi); 
cad  count; 

hi  die  new  imidaDiKatatioii,  die  computaticm  is  shifted  away  from  count  so  that  count  simply 
looks  iqp  die  value  of  die  number  direcdy.  Thus,  die  tiansformatkm  allows  cme  to  get  fttmi 
one  rquesemadon  to  another  in  a  conooUed  manna: 
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Description.  The  abstract  interface  of  the  data^pe  that  follows  has  an  operaticHi  that 
gmeraies  the  datatype,  and  an  toleration  that  returns  stnne  infonnation  about  the  datatype. 

LUerlhoe  Dtype  is 
gen :  Dtype 
obe :  Dtype  /9 

end 

Tbe  observer  (Oieratum  obs  that  returns  some  infonnation  about  the  datatype  perfonns  some 
ccHnputatitni,  represented  by  its  body  O. 

Bepn  Dtype  is  a 
with 

gen  •«=  Abs(G) 

0bs(Ab6(a))  <=  0(a) 
end 

Using  die  shift  transfennatitm,  die  work  is  moved  to  the  (qieradon  diat  generates  the 
datatype,  so  that  getting  information  about  the  datatype  is  now  a  simple  lookup. 

Bepn  Dtype  is 
with 

gen  ^  Abs'(0(G)) 
obs(Abs'(<i))  •<=:  a 

ead 

Sooieof  theeiqnessiveness  of  the  generators  may  be  lost  since  it  is  filtered  out  by  O;  but  this 
does  not  matter  nnce  other  types  can  only  access  this  type  through  the  observer  operations. 

Uaing  the  IWmsfomiathMi.  This  ttansformadem  is  used  to  optimize  datatypes.  It  is 
fiequendy  used  after  the  other  transformations  that  afifect  the  abstract  interfaces.  Once 
operations  ate  grouped  into  die  desired  contmet,  then  a  shift  is  typically  d(»e  to  specialize 
die  result  This  transformadtn  is  used  after  die  aggregate  data  structure  is  derived  tti 
spedalize  the  buffer  operadtxis  in  this  new  context  (see  Sectiem  3.1.6). 

233  Expose 

The  expose  transformation  is  a  **syndietic’*  approach  to  revealing  the  undedying  data  struc¬ 
ture  of  an  existing  datatype.  This  has  the  effect  of  moving  the  boundary  of  the  type  “inwatd.” 
The  data  representadon  of  the  datatype  changes  but  the  meaning  of  the  abstract  datatype 
rranains  the  same. 

Exanqile.  Here  is  a  datatype  for  valuadons  which  is  a  table  of  miqiinngs  from  die  variables 
in  a  program  to  their  values.  This  datatype  has  operathms  to  create  a  new  instance  of  a 
vahiadon,  lodaqi  a  variable  to  otoin  its  value,  and  to  miter  a  new  variable- value  mapinng. 
Moduli  3  [14]  notation  is  used  torepresmitdiis  datatype.  The  abstract  interface  is  specified 
by  a  Modnla-3  interface  defirddon. 
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INTERFACE  Vln; 

TWEt; 

PROCEDURE  NuUvinO :  T; 

PROCEDURE  L0Okup(v :  T;  i :  id) :  Value; 

PROCEDURE  Adj0in(v :  T;  f :  id;  x :  Value) :  T; 

ENDVln. 

The  implementatun  is  specified  by  a  Nfodiila-3  module  definidoD.  Theinidalrqnesen* 
tadoa  is  accdlecdon  of  variable,  value  pairs. 

MODULE  Vln; 

TYPE  T»UST  OF  RECORDS:  ld;v:  ValueEND; 

PROCEDURE  NuUvInO:  T- 
BECON  RETURN  nil  END  NuUvIn; 

PROCEDURE  LookupCv :  T;  j :  id) :  Value  » 

VARp:  T; 

BECaN 

p  vm  PeaocKy,  0;  RETURN  tKp) 

END  Lookup; 

PROCEDURE AdjOifKv:  T;/:  id;x:  Value):  T  « 

BEGIN  RETURN  00n8(00n8(f,x),  v)  END  Adjoin; 

BEGIN 

ENDVln. 

An  alteniadve  way  to  implement  diis  data^pe  is  to  stoxe  the  value  in  memory  with  the 
variable  associated  widi  the  memory  *Tocadon.” 

MODULE  Vln; 

TYPE  Enw  RECORD  I :  Id;/:  LocEND; 

TYPE  State RECORD/:  Loc;v:  ValueEND; 

TYPET—i  RECORD  e:  LISTOFEnv;j:  LIST  OF  State  END; 

PROCEDURE  NulMnO:  T« 

VAR  t :  T; 

BEGIN 

r.onil;  /jr^riH;  RETURN^ 

ENDNuilvIn; 

PROCEDURE  Lookup(v:  T,i:  id):  Value- 
VARp:  Env; 

BEGIN 

p  >  aaaoo(ye,  0;  RETURN  tKa8«x:(y.x,tKp))) 

END  Lookup; 

PROCEDURE  AdjOirKv:  T;/:  id;x:  Value):  T« 

VAR  / :  Loc;  t :  t; 

BEGIN 

/^genlocO;  r.e:-oon8(oon8(/,/),  e);  fx:-oon8(oon8(/,x),  x);  RETURNr 
0iD  Adjoin; 

BKaN 

ENDVln. 
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This  underlying  locatiaii  is  **acpositd^  in  die  tiansfonnadcm  process  oi  the  initial  imple- 
mentatkm  to  eiqilicidy  reveal  die  nuqjiping  ctf  variables  to  locadcxos,  and  locations  to  values. 
In  an  optimizing  ctmipiki;  die  mqiping  of  variables  to  locations  could  be  dene  at  axnpile- 
time,  udiile  now  only  the  look  tq>  of  the  value  at  die  locadcn  would  be  dene  at  runtime.  The 
function  geniocO  generates  a  new  location  in  monocy. 

One  sli^t  modification  to  Modula*3  is  made  to  enhance  the  clariQr  of  the  example.  A 
list  ctnstructor  *UST  OF  a”  is  introduced.  Modula-3  does  not  have  a  list  constructor,  but 
diis  could  be  implmnented  using, 

TYPE  T  ss  REF  RECORD  d :  Data;  link :  T  END; 

DescriptioiL  The  abstract  interface  for  a  representative  coUecticn  of  operatitns  on  the 
datatype  follows. 

DUofMC  Otype  is 
gen:  ntype 
ext :  Dtype  — » Otype 
Obe :  Dtype  0 

CBd 


The  operations  are  defined  cm  the  data  representatitn  a. 

Rcpnotypeiia 

with 

gen  ^  Ab6(G) 
exl(a)  <s  Ab6(E(Rep(a))) 
ob6(a)  <=  OdRofXfl)) 


Applying  the  expose  transformation  reveals  die  underlying  data  structure,  the  tuple 
(ai  X...  xom),  and  produces  new  implementatitms  of  die  operations. 

Repe Dtype  is (ai  x  ...  x  a3 

wtth 

gen  <=  (Abei,...,Abeb)(GO 

ext(a)  <=  {Abei,...,Ab8«>(r«Rep„...,Rep,)(a))) 

ob6(a)  0'({Rep„...,Rep.>(a)) 

The  collection  of  abstraction  functions,  <Ab8i,...  ,Ab6«),  is  q^lied  to  an  n-tuple  to  create 
an  n-tiqile  of  alMtactums.  The  collectim  <rf  representation  functimis  is  similarly  defined. 

Uring  the  IWuisfomiatioiL  The  expose  transfonnatum  is  us^  for  adiqpting  a  dataQrpe 
to  take  advantage  of  qiedal  hardware  or  for  revealing  some  information  about  the  datatype 
duttcoidd  be  partially  evaluated  at  oompile-time.  This  transformatum  is  used  to  decouple 
die  buffer  fiom  die  screen  wdien  intnxhicing  multiple  windows  to  die  editor  example  in 
Cliapler4. 
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23.4  Incorporate 

llie  incoiponue  transfcniudcm  is  usefd  for  specializing  modules  in  the  context  iq>pear 

moving  extBEoalfiinctioDS  or  subcomponents  into  a  module.  This  changes  the  interface 
but  does  not  interfere  with  die  existing  system  because  the  transformation  is  only  ^^lied 
if  dqiendendes  (eg.,  dataflow)  widun  the  program  axe  preserved. 

Exanqde.  I&te  is  me  step  in  die  example  diat  is  shown  in  Sectixm  2.3.6.  A  simple 
abstract  datatype  is  used  in  a  programming  language  interpreter  for  storing  die  bodies  of 
subrmtinedefinitkms.  The  functimMkPdef  is  used  to  create  a  subroutine  definition  given 
its  body  (an  expresskm)  and  formal  parameter  names.  The  functimis  Body  and  Vars  select 
the  components.  Ada  [10]  packages  are  used  to  specify  die  abstract  interface. 

FKkafeFDBFis 

tjpcFdaf  is  private; 

AmdioB  MkRtofCC :  biExp.V:  iBVarList)retBnFdef; 
todta  BodyCF :  IsFdeQiatBrBExp: 
ftoKtioaVBr^:  fai  Fdef)  retun  VarList; 

SBdFDET, 

tactta  Foode(P :  iBFdef)retanCodetype; 

The  extcmal  function  FCode  creates  die  code  necessary  to  execute  die  subroutine  at  runtime. 
It  is  incorporated  into  the  datafype  as  a  prelude  to  flirdier  spedalizaticm. 

FaAateFDEFii 

tjpcFdaf  is  private; 

flncdoaMkFdefCE:  biEj^.V:  lBVarList)retBraFdef; 

Aadta  BodyCF :  laFdaQntanEzp; 

IhMtloaVlBr^:  iBF<te£)remvarList; 

ftoKtiM  Foode(F :  iBFdaf)retaniCo<tetype; 

SBdFDEF; 


Description.  External  functions  are  made  public  functions  of  a  fype  diat  has  the  same 
external  scope.  Likewise,  imported  modules  are  made  substructures.  There  is  a  potratial 
naming  conflict  widi  private  functions  (vriiich  would  have  to  be  renamed)  but  not  widi  die 
pnbtic  functions  because  diey  are  in  die  same  scope.  Public  functions  of  a  type  can  be  made 
private  if  diete  axe  no  references  to  dmn  in  the  external  scc^. 

latartee  Dtype  is 
gen;  otype 
•Kt :  Dtypa  -*■  Dtypa 
Obe :  Dtyp*  -*  a 

sad 

fun: 
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Apptying  the  inanporate  transfonnadon  incluctes  die  external  fimctum  into  the  interface 
of  die  datatype. 

btcrfMC  Dtype  is 
gen:  Dtype 
ext :  Dtype  -*  Dtype 
Obe :  Dtype  — » a 

fun : 

tad 

Using  the  Ihuisfomiation.  The  incorporate  transfonnatioD  is  often  used  as  a  prelude 
to  tpecialiration.  Opentuns  ormodules  could  be  grouped  togedier  for  example,  and  dien 
additional  transfonnadcms  qiplied  to  take  advantage  of  the  close  cotqiling  (eg.,  to  unfold 
calls  to  ftmctions  in  die  type).  Hiis  tiansfonnadmi  is  used  in  Secdon  4.1.3  to  group  the 
buffer  and  die  scxeoi  to  get  better  performance. 

13JS  Release 

The  release  transfonnadtm  is  useful  for  imoving  unwanted  code  after  a  specializadmi 
stqi.  h  can  be  ooosideied  die  apposite  of  incorporate  because  it  moves  funcdcms  or 
subcomponents  outside  of  a  module. 

Example.  Hoe  is  another  stqi  of  die  example  that  is  shown  in  Secdon  2.3.6.  After  Fcode 
(^ddch  calls  Body  and  Vara)  is  incorporated  into  die  datatype,  it  is  deterinined  diat  there  ate 
no  external  lefexenoes  to  Body  and  Vars.  Ada  [1(Q  packages  are  used  to  qiecify  die  abstract 
interface. 

FMfcafeFDEFii 

typeFd«£li  |>rivate; 

ftaaclioB  MkFdel(C :  in  Exp,  V:  inVarList)KtaniFde£; 

ftoKtioB  BodyCF :  iBFde£)ntanExp; 

SncttaVarsCF:  iBFdee)ntanvari4st; 

ftnclioB  FoodeCF :  inFde£)retaniCodetype; 

omIfdbf; 

The  fbncdons  Body  and  Vars  ate  released  frcxn  die  datatype  since  diey  are  M)  Itxig^  used. 

Parkagf  FDEF  is 

typeFdafis  ptlvate; 

AmcttallMtRMtE:  hiExp,V:  iavarLi8t)ictaraFd«£; 

AbkHm  RlodeCP :  la  Fdaf)  return  Codatypa; 

cndFDBF; 
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Dcsoriptioii.  Private  functioos  in  a  ^pe  are  made  public  assoming  no  name  conflicts  are 
inttodneed  into  the  external  scope.  P^lic  ftmctkms  diat  do  not  ctmtain  any  instances  of 
Rep  or  Abe  for  die  defined  ^pe  can  be  made  extenial,  provided  diat  all  private  functions 
called  by  any  of  the  public  functions  are  made  public.  lilrewise,  substructures  can  be  made 
a  sqiarate  module  and  dien  imported. 

iBlafMeDtypeis 
gen :  otype 
ext :  otype  — » Dtype 
Obe :  Dtype  -*  a 

fun: 


Applying  die  release  transformation  removes  the  function  ftem  the  datatype. 

latofMC  Dtype  ii 
gen :  otype 
ext :  otype  — » Otype 
Obe :  otype  a 

fun:  0-*^ 

Uaiiigtlie'nraiiaferiiiidioiL  The  release  transformation  is  ^pically  used  as  a  prelude  to 
qiedalization,  or  to  lenioveoperatiaiis  tint  are  no  longer  useful  after  a  qiecializatimL  This 
transformation  is  used  in  Section  3.1.6  to  remove  redundant  information  from  die  buffer 
aggregate  once  final  deagn  dednons  are  made. 


23,6  Strategies  for  Using  the  Module  Thmsformation  Rules 

The  transformatioiis  are  typically  used  iQgediei;  for  exanqile,  to  move  boundaries  as  a  pie- 
lude  to  gieciaMzarion  or  shifting.  Here  is  an  example  taken  from  Jsrring  and  Scheriis  [48], 
of  one  such  transformation  on  a  data  representation  diat  has  a  0aiect  effect  cm  program 
perfinnanoe.  A  simple  abstract  datatype  is  used  in  a  programming  language  interpreter  for 
storing  die  bodies  of  subroutine  definitions. 

lalarftmrdsf  is 

MkFUef:  Xaqp  x  Vax* Fd«f 
Body :  rd«f  -» asp 
Vbrt:  r<laf-»var* 


The  functian  MkFdef  is  used  to  create  a  subrocitine  definition  given  its  bocty  (an  mqaession) 
and  fionnal  parameter  names.  The  fhnetioas  Body  and  Vais  select  die  componoits.  When 
a  sobromine  definition  is  encountered  by  the  intennetei;  MkFdef  is  called  to  create  die 
oorrespoofingobiiecL  Fdofs  are  represented  as  pairs. 


2.4.  Straugies  in  Conamaing  Systems  Using  Ms  Approadi 
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EqNi  Fdef  il  Exp  x  Var* 

with 

MkFdel(E,V*)  Ab6(con8(£,v*)) 

Body(D)  hd(Rep(D)) 

VarsP)  tKRepCD)) 

mi 

Sobrootiiie  calls  are  carried  out  die  ftmcdon  Apply.  When  the  suhrcwtine  F  with 
die  actual  parameten  V*  is  encountered,  die  name  of  subroutine  is  looked  iqi  in  the 
ITOgram  coviroomentPEwv  to  obtain  die  Fdef  consisting  of  die  robroutine  body  and  formal 
parameter  names.  The  function  Apply  has  twoidiases.  It  cooMructs  die  randme  code  needed 
for  executing  the  subroutine  in  die  tot  idiase.  Thai  it  q^lies  die  actual  parameters  to  the 
code  widiin  die  program  environment  in  die  second  jdiase. 

Apply(F.V*,F£mO  <=  letZ>«find(P£iiv.  f)iB 

let  code  «  Phasa1(Body(D),  MkEnv(Var8(D)))  in 
Pha8a2(aNte,  v*.  pehv) 

Observation:  The  tot  {diase  could  be  carried  out  less  fieqnendy  if  it  were  done  at  the 
dmediatsubrontiiies  are  defined  ladierdianadieadiey  are  called.  T^  is  accomplished  by: 
iUtstracting  Phasel  into  the  function  Foode,  inanporating  FPode  into  die  ^pe  signature, 
shiffOng  PhaMi  from  FCode  to  MkFdef,  and  releasing  Body  and  Vars  from  the  data^pe 
tinoe  diey  are  no  longer  referenced. 

Sepn  Fdef  is  Codetype 

with 

MkFdofCE,V*)  Aba'tPhaselCF,  MkEnv(V*))] 

Foode(D)  ^  Rep'KJl 


Appiy(F,V*,F£iiv)  ^  letl>«find(P£iiv,f)fB 

let  code  >  Foode0>)  in 
Pha882(code,  V*,  PEm} 

In  die  new  implementation,  two  things  are  happening:  context  outside  of  the  ^pe  is 
incorporated  into  the  9pe,  diat  is,  the  boimdary  is  widened;  and  consultation  is  shifted  from 
adiea  subroutines  are  called  to  triieadiey  are  defined,  diat  is,  internal  data  refinement.  The 
transformation  allows  die  srrftware  developer  toga  from  one  representation  to  another  in  a 
controlled  manner. 


2.4  Strategies  in  Construcdiig  Systems  Using  this  Approach 

The  duee  mediods  of  integrating  components,  adding  new  consioneats,  and  adi^ting 
modnle  interfaces  described  in  Section  2.1  are  part  of  a  similar  integration  process.  The 
end  result  of  eadi  process  is  a  ooDection  of  data  transform  procedures.  The  module 
transformation  rules  described  in  Section  23  can  then  be  applied  to  them  to  yield  efficient 
inqiiemeatatkais,  Pmting  the  rules  and  die  ini^ration  processes  together;  a  process  for 
constnicting  systems  using  this  iqiproach  is  defined. 
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The  eaential  siqit  for  implnneiuing  dati^pes  or  modules  by  oonqxnokts: 

1.  Specify  die  interface.  The  names  of  the  opentioiis  are  listed  widi  their  signature. 

2.  Define  the  component  implementations,  each  of  trfuefa  implements  some  subset  ci 
dieiniBifooe.  Ccdlectively,  all  of  die  components  implemeot  die  entire  interfsce. 

3.  Establish  any  data  invariances  amongtfae  components  by  defining  functicHisdiattrans- 
laie  from  one  component  into  anodier  to  cattablish  die  consistmicy  of  die  coUectum 
of  data  rqpresentations, 

4.  Choose  u  an  **expedienf*  representation  the  product  of  the  component  xqnesoita- 

5.  fiuegraie  die  coniponents  to  define  the  data^pe  or  module.  Each  operation  d^ned  in 
aconqionent  indnoes  aoorresponding operation  on  the  aggregate  datatype  or  module. 
Eadi  opendon  definition  is  put  into  a  format  amenable  to  transformation. 

6.  fayienient  die  datat^te  or  module.  Since  die  definitinns  are  data  transform  pro¬ 
cedures,  diis  is  done  by  applying  transformations.  The  eiqiresaon  procedures  are 
tcsnsfonnedintofimctional  definitions.  Whenadiq>tingdiesystem,itmaybepo8sible 
to  reuse  some  of  die  infonnatian  firam  die  derivation  of  die  integration  (rf  die  original 
system. 

7.  Uncover  an  cflkiem  representation  by  eliminating  unnecessary  redundancy  and  spe- 
daUziiig  data  in  the  context  diat  it  iqipean  in. 

8.  IniplenientaneflScieminqdemcaitatiooby  tianslatinn. 

Figure  2.1  (seen  at  the  b^inmog  of  ddsduqner)  is  an  abstract  view  of  this  process.  The 
process  starts  widi  die  design  of  d»  top-level  aggr^ateqiecification(siq)s  1,2  and  3).  The 
softwaredesignerudio  wishes  to  design  a  complex  system  is  able  to  decompose  die  prob¬ 
lem  iitto  components  dutt  best  model  diat  portion  of  to  proMem.  Theoonqiooentsmaybe 
obtained  from  a  libraty  or  prototyped  by  to  designer  using  a  data  r^rrsentatkindutt  most 

datarepresentatinns,  TTds  definition  is  used  in  to  jutegnaioit  phase  to  produce  an  aggregate 
definition  (stqis  4  and  5).  Obtaining  to  aggregate  definitioo  from  to  aggregate  spedfica- 
tion  is  a  mectoitical  process  that  am  be  eiqiressed  as  an  algoridmi  (see  Section  6.1.4)  once 
oomparibflity  mips  (which  reyea  to  ooaristency  relations)  are  provided.  Theaggregate 
definition  is  in  a  format  lyonudiidi  data  nanslations  (Section  23.1)  can  be  performed  to 
obtain  an  execundiie  pmto^fpe  (stqi  6).  limn  additional  ttansformations  such  as  ogsmse, 
incorporate^  rtkau,  and  (Seokm  23)  are  performed  to  optimize  to  ptosacypt  into 
an  efficient  imptemernaSkm  (peps  7  and  8).  Lata  on  to  software  designer  mi^  wish  to 
imroduoe  ackfitioiud  functionaHty  in  to  adapt  phase. 


Chapter  3 

Int^atii^  Module  Interfaces:  Deriving 
and  Manipulatii^  an  Edit  Buffer 


In  onkr  to  demonstrate  die  tediniqiies  for  integrating  module  mterhioes  by  piogram- 
transformations,  we  now  go  dnoug^  an  exerdae  in  die  development  of  a  simple  interactive 
lexteditac.  ^woricduxn^  the  derivatioo  of  die  text-buffo  implemmitatioomSection  3.1. 
Ihen  we  intiodnoe  additional  functionality  in  Section  3.2  to  examine  how  the  tnt  buffo 
isadqited.  hnportmtconcqita  (sudi  a  “componenQ  are  informally  introduced  here,  widi 
dieirnaineiniaificf.  A  giosiaty  of  dieae  terms  is  avmlable  in  Appendix  B.  All  such  names 
in  italics  are  predaely  defined  in  Clu^pter  d. 

Datatype  definitions  are  iqaesemed  as  modules  written  in  a  notation  based  on  an 
extended  form  of  Standard  ML  [dO].  The  extenrions  add  notation  that  is  described  as  it 
is  intcodnoed  in  the  exanqdes.  AlAou^  die  decision  was  made  to  base  the  notadtm  tm 
Standard  ML,  as  shown  in  die  previous  chqner,  die  transfonmadon  techniques  are  language 
indqwndeiit  and  can  be  qiplied  to  odier  languages  widi  modules  sudi  as  Ada,  On,  and 
Mot^  3.  Standard  ML  also  has  some  high-level  abstraction  mechanisms  to  facilitate 
die  design  of  datatypes  and  duu  allow  one  to  focus  on  the  module  structure  and  overall 
arddiectnre  of  die  system  tidier  dian  getting  lost  in  die  details  (vrinch,  aldion^  intyortant 
at  later  stages  in  derign  and  development,  obscure  die  system  structure  dutt  one  is  focusing 
on). 

Odiernocatioos  to  consider  are  iqiecification  languages  diatstqiport  die  design  of  large 
programs  sodi  re  Lardi  (381  and  Z  [84].  Indeed,  die  style  of  develofnng  systems  in  these 
languages  has  htfluenoed  die  stjie  of  edilcpderivation  presentation.  However,  since 
spedficsiioos  drel  widi  a  U^ier  level  of  abstraction,  it  is  necessaiy  to  use  a  language  in 
which  abstract  imerfooes  and  data  repeT.srjitiuiont  can  be  defined  and  manipulated.  The 
dedsion  was  made  to  use  Standard  because  it  has  an  elegant  module  facility  and  folly 
defined  senuadcs  [61].  Moseovei;  Extended  ML  adds  a  useful  extension  to  die  language, 
foe  ability  to  add  axioms.  This  gives  foe  software  derigner  a  wide-tpectrum  language  to 
represent  hjgfaer-level  ipecificarions  that  can  be  refined  to  an  ingdenaaitaMe  subset  See, 
far  example,  SanoePa  red  Thriedd  [72],  where  a  metfaoddogy  fo  software  development 
is  developed  using  ML  modules  extended  widi  axioms. 
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3.1  Deriving  the  Buffer 

In  tidsderivaiioo,  tile  edilor  is  designed  initially  as  a  collection  of  sqMgateccmiponeiits. 
The  collection  of  ccMBponents  is  integrated  by  deriving  new  module  interfaces,  resulting  in 
an  executable  proto^pe.  Then  ^fidency  transfionnations  are  sf^died.  The  entire  pfocess 
is  dqncted  in  Rgure  3.1,  liriucfa  is  referred  to  in  the  mtample  as  die  steps  are  elaborated. 

3.1.1  Program  Design 

We  are  now  reatty  to  design  die  data^pe  of  die  text  buffer.  We  start  by  dining  the 
abstract  interface  of  die  datatype.  An  ntoracr  is  simply  a  signature.  We  use  a 

Standard  ML-tike  signature  declaration  to  qpedfy  abstract  int^aces. 

The  following  spedfication  defines  an  abstract  intesface  for  die  datatype  buf  and  the 
aevoi  buffer  operations:  makebuf,  delete,  bisert,  move-left,  move-fight,  show-char,  and 
next-line. 


SgUtSICBOFsa^ 
type  buf 

makebuf:  buf 
delete:  buf -» buf 
insert:  eh  x  buf buf 
move-left :  buf  — *  buf 
move-right :  buf  buf 
showchar :  buf  ch 
next-Nne:  buf -» buf 


The  next  stq^  is  to  design  the  data  structure  of  die  buffer.  Our  goal  is  to  arrive  at  a 
single  data  representation  diat  siqqxKts  die  effidmt  imidemmitation  of  all  of  the  operatkms. 
Since  designing  a  data  representation  diat  is  satisfact^  for  aU  of  die  operations  may  be 
difBcolt,  we  be^  by  implementing  subsets  of  die  operations — each  subset  comprising  a 
corrfNMertf — and  then  try  to  integrate  diem  later. 

3.1J2  Program  Composition 

The  move  operations  are  conveniendy  imirieinenied  by  using  a  representation  diat  is  a 
sentence  of  clmactenwidi  an  explicit  index  for  die  point  where  editing  takes  place.  The 
point  of  eddng  is  moved  left  by  decranenting  the  index  and  moved  xi^  tty  incrementing 
die  index.  The  dmacier  at  die  point  of  editing  is  retrieved  by  looking  iq>  die  character  in 
die  text  to  die  left  of  die  index.  (The  element  of  a  sequence  sis  denoted  sin].)  The 
conqwneatimpiementaiionriiown  below  is  based  on  drisrqneseniation.  The  notation  used 
for  the  component  definition  is  similar  to  the  Standard  ML  structure  dedaratioo.  It  is 
called  a  coiqponent  becanae,  imlike  a  structure,  not  all  of  die  operations  in  die  signature 

terms  of  the  *f**»»f" 

of  iatqprs  and  diaraciBr  sequences  (-*  being  die  sequence  type  oonnructor). 
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Ownpoff  Buf  1 :  BOF  IS  Kract 

Ijpc  buf  s  Buf  of  (int  X  ch*) 

move-I^Buf(p,0)  <<=  Buf(p-i,  f) 
move-Tight(Buf0»,0)  <=  Buf(p<fi.  0 
8howH:har(Buf(p,0)  ^  tlp-i] 

taaetniaiButipyt)  >0  0<p<it 

cad 


Abstraction  of  the  underlying  datatype  lepresentitioQ  is  maintained  using  the  datatype 
oonstmetor  Buf.  Used  on  die  lefdiand  side  of  die  (Rendon  definition,  the  text-buffer 
rqgesentatkw  is  "^revealed.**  Only  opentions  defined  within  die  datatype  can  use  die 
datatype  constructor  in  ddsmannec.  Usedontheri^iduuidsideofdieoperaticmdefinititm, 
die  representatuMi  is  **hidden.**  This  provides  an  abstraction  boundary  where  operatiems 
defined  outside  of  die  cemponent  are  not  allowed  access  to  die  data  rqnesentaticML 
Constraints  are  axioms  diat  contain  additional  infonnatimi  such  as  invariants  cf  a 
datatype  mqiressed  in  first  order  logic  (where  finee  variables  are  universally  quantified  and 
^  is  logical  implication).  The  constraim 

Buf(p,r)  =►  0<p  <  it 


is  an  abbreviation  for 

V6 ; buf , Vp :  int,Vf :  ch*  |  b *=  Buf(p,r) ,0<p<it. 

Extended  ML  172]  gives  the  developer  tins  ability  to  add  axioms  to  structures  (and  signa¬ 
tures).  Gonstraiiits  mity  be  used  as  enabling  conditions  to  provide  additkxial  context  for 
transformations  (see  ^^lendix  C).  Constraints  may  also  be  refined  in  the  implementatimi 
so  that  they  are  satisfied  by  eadi  operation  (see  Section  3.1.6). 

In  die  exanqile,  die  aidkim  constrains  die  index  to  remain  widiin  die  boundaries  (rf  die 
text  (#s  denotes  die  cardinality  of  die  sequencer).  The  result  of  moving  the  index  beytmd 
die  bounttary  is  undefined  at  diis  stage  in  the  design.  Later  on,  as  the  component  is  refined 

intoan  implemeiitation,  BMiiecnmmilinMiti  handling  rm  tii»in«ri»>  tn  mam  tlmt 

eadi  operation  cannot  violate  die  axioiiL  Fbrexample,  die  inove  operations  couldreium  die 
buffer  undianged  if  an  attempt  is  made  to  move  out  of  die  buffer  boundary.  An  alternative 
is  to  return  an  enor  value  or  flag  so  that  a  "beep”  from  the  tenninal  could  be  emitted  or  the 
scieenfladied.  This  would  necessitate  adqiting  die  al»tract  interface  v^iich  is  discussed  in 
die  fbOowing  duqnec 

This  component  definition  provides  ample  and  natural  definitions  for  die  three  opera¬ 
tions  shown.  Implementing  insertion  and  deletion  of  characters  in  diis  Buf  I  representation, 
on  die  other  hand,  requires  an  inconvenient  (and  hence  error-prone)  manipilation  of  sub- 
sequenoes  widiin  the  text  A  more  convenieiit  representation  for  diese  new  operations  is 
a  pair  of  chancier  sequences,  representing  the  duuacters  to  the  left  and  to  die  ri^  of  die 
pohn  of  editi^  The  index  for  die  poim  of  editing  is  left  inqdiciL  A  character  is  deleted 
by  removing  die  last  elemeat  from  the  left  seqoeiioe.  A  dunacter  is  inserted  by  qipending 
it »  die  left  sequence,  /  #  [c].  There  is  no  constraim  on  dus  component,  diongfideleta  is 
unspecified  when  at  the  be^mting  of  die  buffet 
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CompoBctf  Buf 2 :  BUF  sstract 
typebaf  «  Buf  of  (ch*  x  ch*) 

makebuf  Bufai,  [D 

deiete(Buf (/  #  [c],  /■))  <=  Buf (i,  r) 

b«ert(c,  Bu£(l,  r))  4S  Bu£(l  #  [c],  r) 


AMKHigli  tiie  makebuf  operation  is  included  in  tins  CCTnpCTieat.  it  could  have  just  as  easily 
been  defined  in  tile  first  ctBnpooeat  as  makebuf  Bu£(0,  []). 

The  next4irieq;)ention  moves  tbepdntofediting  to  tile  following  line  witii  tile  character 
position  in  the  line  remaining  the  same.  This  is  difficult  to  implement  using  either  of 
tiie  previoas  representations,  since  it  requires  searching  for  newlines  and  ctmiputing  the 
distance  between  die  point  of  editing  and  the  preceding  newline.  For  this  tqieratimi,  tiien, 
a  new  component,  Bufs,  is  introdnocd  where  tiie  text  is  a  sequence  of  lii»s  (wlmre  a  line 
is  a  sequence  of  characters  not  ccmtaining  a  newline)  and  tiie  point  of  editing  is  a  line 
and  duoacter  position.  Then  the  point  d  editing  is  moved  to  the  next  lii»  simply  by 
incrementing  tiie  line  position  by  one. 

CoasponcatBufs :  buf  astruct 

l3Velln««(ch- W 

tjpc  buf  a  Buf  of  ((int  X  int)  x  line*) 

next4ine(Buf(((p,<;p},o))  Buf({(p<f  o) 

rnmtntar  Buf({i(p,q>),  ts)  0<lp<its 

cnwtmhit  Buf((i^,qp},<r)  0<q><  itsllp] 


The  newlines  are  inqilidt,  giving  a  more  compact  rquesentatitm.  Of  course,  if  one  so 
chooses,  an  alternative  rqxesentatkm  can  be  us^  dut  keqis  a  newline  character  at  the  end 
ofeachUne.  Ihe  first  invariant  constrains  die  line  pointer  to  remain  widiin  die  boundaries 
of  dm  bofien  The  second  invariant  emuttains  die  diaracter  index  to  remain  witidn  the  line 
dun  it  is  on.  As  in  die  definition  for  Bufi,  die  result  of  moving  die  point  of  editing  beymid 
the  boundary  is  undefined  at  tins  stage  in  die  design.  Not  only  does  tiiis  happen  when 
trying  to  move  past  the  last  character  of  a  line,  or  past  die  last  line  of  die  bufifer;  but  also 
when  trying  to  use  next-fine  to  move  from  one  line  to  the  next  that  is  shorten  This  invariant 
can  be  refined  at  a  later  stage  in  the  software  devdopment,  for  exampte,  by  moving  to  die 
same  diaracter  podtion  widiin  die  line  if  possible,  but  moving  to  die  end  d  the  line  if  die 
fdlowing  line  is  shorter. 

3.13  Aggregate  DesigD 

GoQectively,  diese  diiee  compooents  implement  all  of  die  operations  of  die  abstract  inter- 
fiaceftsTBUF.  However,  in  onkr  to  use  all  of  the  operations  interchangeably,  an  **agreemmir 
amav  die  various  data  iqxeseatatkios  must  be  readied.  These  data  iqxesentations  are 
easenriaWy  **views**  [29)  or  projections  of  some  aggr^aie  buffer.  Oreway  toreadiasme- 
ment  is  to  define  consistency  rekrions  among  die  components,  of  die  fonn  i  map(  J.  An 
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aggregate  tgrec^ication  specifies  a  datatype  constructed  from  a  coUectioa  of  compcxients 
and  consistency  lelatuns,  and  has  the  following  prcq)erties:  there  are  projection  fuiK^ticHis, 
li^iich  nu^  the  aggregate  data  object  to  an  object  of  a  particular  compcment;  and  evoy 
oompCMient  operatkm  induces  a  corresponding  q)eratuHi  in  die  aggre^ue  that  maintains  tte 
consistency  of  die  cnnpooents.  The  aggregate  specification  encapsulates  die  complexities 
diat  were  avoided  by  not  defining  die  tqientimis  in  all  of  die  comptments. 

Using  dus  definitum  in  our  example,  then,  an  aggregate  text-buffer  is  defined  in  tmms  of 
the  components  Buf  i,  Buf  2.  and  Buf  3,  along  with  die  ctxisistency  reladmis  that  qiedfy  the 
agreement  among  these  components  (Rgure  3.1,  design  step).  Aprojecdcmofanaggre^tte 
buffer  data  olgect  yields  an  object  ci  a  particular  amip(»mt,  ami  each  siuih  ccxnponent 
objea  is  rdated  to  odier  compoomt  objects  by  consistency  relatitms  (which  is  formally 
ddSired  in  Section  6.1^).  Intuitively,  diese  relations  provide  a  notitm  of  consistency  for  the 
aggregate  data  objects. 


buf 

In  order  to  avoid  ambiguity,  names  of  ^ypes  and  operations  are  prepended  with  the  name  of 
the  component  in  which  it  was  denned.  For  mcample,  each  of  tte  components  define  a  type 
buf  soBufiJbuf  referstodietypedefinedindiefimconipmienL  lb  mihance  the  readability 
o£  the  examples,  these  "qualified”  names  are  abbreviated  by  omitting  the  component  name, 
and  using  die  component  number  as  a  subscript  widi  die  type  or  toleration  name.  For 
example,  buf  1  and  move-righti  are  abbreviaticuis  for  Buf  1  J>uf  and  Buf  1  .move-right 
Ibe  effect  of  an  operation  on  a  text  buffer  is  defined  in  terms  of  die  corresponding 
compoDent  operation.  In  die  aggregate,  the  operation  must  ensure  dial  die  ejections  of 
die  buffer  remain  consistmit  This  is  expressed  in  the  following  commutative  diagram. 


The  relationships  depicted  in  diis  diagram  can  be  specified  via  axioms  on  die  opcratirais  in 
die  vatimis  components.  Sudi  axkms  are  wiittmi  along  widi  die  abstract  interface  the 
daa^pe  (eg.,  adding  axioms  to  die  abnnet  interface  for  the  buffer  shown  in  Section  3.1.1). 
Doing  so  results  in  an  amiotated  abstract  interface  giedficatiai  duu  includes  a  qiedfica- 
don  of  componeni  integration.  As  an  mounple,  the  axioms  for  move-right  are  diown  in 
HgureSJ. 
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aiiiMipraji(move-right(d))  »  move-righti(prpj,0)) 


nkMiprpiid^)  mart  prpla^) 
aiioBpn^(d)  mart  prajjC*) 
«d(Miprrt,(6)  mart  proii(6) 


"=>  praji(move-i1ght(fr))  mart  praj2(iTK>ve-rlght(»)) 
"=>  praijCmoveHrlghtCi))  nurt  prajjCmove^htCd)) 
"=>  prpijCmoveHrighKd))  mart  pn)]i(move-right(6)) 


Hgtne  3d.:  Buffer  Aggregate  Specification  for  Move-Rigfat 


3.1.4  Aggregate  Integration 

An  aggregate  definition  is  a  datatype  duu  refines  die  aggregate  spedficadrm.  The  data 
rqnesoitation  is  defined  as  the  product  of  die  componoit  data  tepresentadrnis  and  the 
operaticxis  ate  defined  in  terms  of  the  compcment  operations  as  “data  transform  procedures” 
(Hgure  3.1  .integrate  stq>). 

Data  vransfiorm  procedures  define  alternative  implemoitatums  on  data  representations 
in  a  way  similar  to  the  data  transformation  definitums  presented  in  Section  11.  They  may 
take  mie  of  two  forms: 

1.  Given  a  program  fusing  a  data  tqxresentatiim/>  and  a  functicm.  span,  that  translates 
elmnents  of  the  data  representation  D  to  elmnents  of  the  data  rqnesentation  D\  we 
define  fas: 

fl(span(4))  ■«=  8pan(f(4)) 

2.  If.  instead,  diere  is  a  fiincticm.  unspan,  diat  translates  elmnents  of  die  data  represen- 
tatimiiy  to  elements  of  the  data  representatitm  D.  we  d^ne  f  as: 

un8pan(f(4))  <«=  f(un8pan(4)) 

This  style  procedure  definition  is  called  an  “eaptessicm  procedure”  by  Scheriis  [74]. 
While  the  eiqnessitxi  procedure  definitum  for  f  may  not  suggest  an  implementaticm.  syn¬ 
tactic  transfonnations  can  be  applied  to  obtain  a  fimctimial  definition  for  the  prc^ram  f 
on  die  data  rqnesentation  U.  'iit  saw  examples  of  transforming  data  reptesentaticms  in 
Quqner  2  in  die  sections  on  die  translate,  shift,  and  expose  transfonnations.  We  will  see 
in  Chapter  6  how  di^  are  mcplained  in  terms  of  data  transform  procedures.  Since  more 
than  one  opention  may  occur  on  the  lefdiand  tide  of  an  eiqnessimi  procedure  definiticxi. 
there  may  be  some  confusion  about  which  operation  is  bong  defined.  Because  of  this,  the 
operation  bring  defined  is  underlined  to  distinguish  it  from  the  odiers. 

Frilowing  diis  appeoeeb,  a  periiminary  dilution  ol  move-right  <»  die  aggregate  is 
obtained  (Hgure  33).  Recall  that  move-right  is  defined  in  componmit  Bufi.  Alternative 
versions  ai  move-right  for  die  other  componrots  (i.e..  move-righ^  and  move-rights)  are 
defined  as  data  transform  procedures  in  terms  of  tbe  Buf  i  definition  emee  “compatil^ty 
nuqps**  (f.a..  mapj.,^  vdiidi  serves  as  unspan)  betwem  die  ccanponents  have  been  defined. 
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mapi^idnow-fight^W)  <=■  mov»-rloht,(mapi_,(6)) 
nfiapi_>i(move-rioht^(d))  <=  move-righ^(map}_^i(fr)) 

move-rigrit(Buf(p,f,/,r,{(p,(p),(f))  <= 

BufO^,  f,  r,  {V,cp^),  «i0 

when  Bvif lip’, f)  m  move-rl(^(Bufi(p,  0) 

•DdBufxC^.O  >  mov»-i1gri^()Bu£2(/,  r)) 
w»ABaUiilpf,qff),t^  «  move-fiohi(Bu£j(((p,<y>,  tt)) 


Hgiue  3.3:  PreKminaay  Definition  <tfNfove-Ris|it 


A  compadbUity  map  is  a  function  fiiat  respects  fiie  consistaicy  relatitXL  It  translates 
one  componoat  rqaesentatkm  into  another  represematiML  Dq)a)^g  on  the  c(»isistency 
relatum,  it  may  not  be  possible  to  impkmmit  compatibility  mi^  in  both  diiecticms,  but 
nonnally  it  will  be  straightforward  to  implonmitone  of  diem. 

The  alternative  versioos  of  move-right  ate  defined  by  data  transform  procedures  where 
die  compatibility  nuqis  serve  as  the  span  or  unspan  functions.  The  data  representaticm  of 
the  aggregate  is  die  product  of  die  componmt  rqnesmitations.  The  move-right  (deration 
oa  the  data  aggregate  is  d^ned  as  the  product  of  die  compooern  opeiatums,  vdiere  each 
component  operation  updates  the  appropriate  fields  of  the  aggregate  rqaesoitatioo. 

This  definition  is  easy  to  conrtnict,  but  is  constrained,  however.  The  implemoitations 
of  move-right  for  the  other  components,  move-right2  and  movenlgh^,  only  make  use  of  durir 
**own**  representations,  that  is,  Buf  2  and  Buf  3,  respectivdy.  Thus  we  are  not  able  to  take 
full  advantage  of  any  intertelationriiips  among  die  various  rqnesmitatitHis  when  deriving 
an  implementation. 

A  more  general  qiproach  is  to  arrange  for  all  of  die  component  rqnesentatums  to  be 
available  for  die  operation  definitions  in  order  to  take  advantage  of  any  inierrdationships 
amwig  the  various  rqnesentations.  Going  back  to  die  preliminary  definitum  die  aggre¬ 
gate,  instead  of  actually  deriving  inqilementations  for  die  component  operatitms,  die  data 
transfonm  procedure  itself  can  be  symbolically  manqmlated  to  yield  a  new  definition  for 
die  aggregate. 

The  buffer  definition  shown  in  Rgure  3.4  uses  dus  qiproach;  here,  die  buffer  operations 
(after  die  keyword  in)  are  again  defined  by  data  transform  procedures.  In  taking  advantage 
of  diis  added  generaUty,  die  operations  are  defined  in  terms  of  die  aggregate  buffer  rqne- 
senunion,  or  some  portion  of  this  representatkm.  Then  inqilemmitations  of  the  cqieratitxis 
are  derived  with  all  oontyonoit  tgaesentarions  available.  To  nu^  betwemi  die  components 
and  the  various  aggregates,  **span”  and  **nnspan*’  fonctions  are  used  (after  die  keyword 
local  in  die  figure)— diis  also  has  die  effect  putting  dungs  into  a  form  suitable  for  data 
transformation.  The  constraints  on  die  aggregate  (at  die  bottom  of  the  figure)  ate  obtained 
from  the  consuaints  on  die  components. 

The  translation  functions,  span  and  unspen,  for  die  data  transform  procedures  are 
defined  in  terms  of  die  conqiatilnlity  miqis.  A  ^pon  functitm  is  a  mqifnng  from  one 
componau  into  die  aggregate  <rf  all  reocfiobfecompOTients  (i.e.,  connected  by  compatibility 
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Siracfare  Buf :  BUF  s  atract 
ftractaoreBufi,  Bufa,  Bufs 

Qrpebuf  at  Buf  of  (int  x  ch*  x  ch*  x  ch*  x  (int  x  int)  x  line*) 

local 

mapi,_i(fiu£2(/.r))  «=  Bu£i(#/, /®r) 

map,^,(Bufs({(p,<y>,ii))  ^ 

Buf  i(«0ineB4(Hjhar8(2s  - 1)] ))  -f  Unes-lo-^ha^ts)) 

where  lines-to-Gha^j) « if  thea  [  ] 

dee  [hd(f)]  #  [‘nl’]  #  line8-tx>-Ghars(ti(f)) 

8pan.(Bu£a(/,r))  «= 

Bu£ixa(Pf  t,  I,  r) 

where  Bu£i0»,0  -  fTM|3j^j(Bu£a(/,  r)) 
un8par^(Bu£(p,r,/,r,<4»,q»).<j))  <= 

Bu£ixa({p  I  /b}.  {<  I 

whereBu£i(p4,(3)  »  mapj_i(Bu£3(((p,qp),  «s)) 
un8pan,(Bu£(p,<,/,r,«p,q»),tt)) 

Bu£i({^  I  i  ^  }>  {  M  <2  I  ^  )) 

where  Bu£i(^,<a)  -  niaft^i(Bu£a(/,  r)) 

aiidBu£iO»3,»3)  -  maR,_,(Bu£3({4>,q»>. »)) 


in 

niakebufix2  8pan,(makebi4i) 
unopan^fmakebuft  makebufixi 

unspan^(mova-right(^))  <=  move-right, (unspan^Cfr)) 

ahow-charCfr)  ^  8hcw-chari(un8pan,(fr)) 

nfi8fc!lDfijx3(8P«n/W  ^  8pan/next-llne3(W 
un8pan.(Dffl5tliDfl(W  <=  ne)(t-ilneix3(un8pan,(ft)) 


conetralaf  {lp,q>),u}  0<p<*t 

moalrelat  Buf^,r,/,r,  {ip,cp),tii  0  <  fl?  <  #» 

ronetralat  ^,cp),ts)  0<i^<§tsHp] 
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maps).  An  unspan  fimctioii  is  a  iiiq>ping  from  some  aggregate  of  componmits  into  die 
conqiooent  diat  is  readied  by  all  of  dim. 

The  definitions  of  die  tqienoions  and  spanning  functions  are  not  od  hoc:  diey  are 
olnained  mechanically  by  CMsidering  die  onier  in  idiich  die  compcments  must  be  “meiged.” 
The  basic  idea  is  to  coiisito  die  buffer  definitimi  as  a  gn^h,  ndiere  die  oomptments  are  nodes 
and  die  oonqiatibility  nuqis  are  directed  arcs.  The  cyciations  for  each  comptmmt  must  be 
leimidCTentedtoopexateoadieaggregaie.  This  is  done  in  a  series  of  stages.  Startingatdie 
node  iqiresenting  die  component  idiere  the  operations  are  d^ned,  all  connected  nodes  are 
merged  into  a  new  "coalesced**  node  usiog  a  variant  of  die  data  transfonnatitm  techniques. 
This  "coalescing**  of  connected  nodes  is  repeated  until  die  gnqih  colliqises  into  a  sing^ 
node.  (See  Section  6.1.4  for  more  details.) 

In  die  definition  shown  in  Hgure  3.4,  Buf  implmnents  die  abstract  interface  buf  using 
die  conqiooents  Buf i,  Bufj*  and  Buf 3.  A  rqnesoitative  sample  of  tqierations  is  shown. 
Defining  die  makebuf  operation  for  the  aggregate  requiies  two  stages  because  the  Buf2 
component,  in  udtich  it  is  defined,  is  not  directiycminected  to  all  the  odiercmnpmients.  It 
is  connected  direcdy  to  Buf  1  via  a  compatibility  map,  but  indiiecdy  to  Buf  3.  In  the  first 
stage,  an  intennediatB  definition  of  makebuf  is  defined,  makebufix2>  on  an  intermediate 
aggregate,  Buf  ix2«  (dierqneseotation  is  the  product  of  the  Buf  1  and  Buf  2  representations). 
In  die  second  stage,  die  final  operation  on  the  aggregate  buffer  is  defined  by  merging  diis 
intermediate  definition  with  the  Buf  3  componmit  Since  die  Buf  1  componoit  is  direcdy 
connected  to  an  odier  components,  new  impkanmitatioos  for  die  operations  (Mned  in  diis 
component  (eg.,  move-i1(^  and  showKdiar)  are  defined  in  a  singte 

The  oonqxments  are  kqit  consistent  dnough  the  conqiatitnli^  nuqis  map2-«i  and 
map3_i.  n  ia  not  necessary  that  aU  translaticms  among  components  be  given;  it  is  sof> 
fidem  diat  die  components  are  connected,  possibly  dirou^  some  number  t£  intermediate 
components.  Component  Buf2  is  nuqiped  into  componmt  Buf  1  by  making  the  point  of 
editing  eaqilidt  (which  is  die  number  of  characters  to  the  Idt  of  die  point,  #0,  and  by 
qqimiding  die  left  and  right  sequence  of  characters  togedien  Component  Buf  3  is  m^iped 
into  conqionent  Buf  1  t^convertiogdie  line  anddiaracterindkesintoacharacterindex  and 
by  converting  die  sequence  of  lines  into  a  sequence  of  characters.  The  auxiliary  fbnctitm 
line8>to-chars  takes  a  sequence  of  lines,  adds  a  newline  to  die  end  of  each  cne  and  appends 
diem  to  make  a  sequence  of  characters.  (The  notation  sM]  dmiotes  the  subsequence  of 
s  firom  die  beghming  of  s  to  j  inclusive.)  The  translation  functions  are  easily  defined  in 
terms  die  compatibilhyiniqis.  In  die  definitions  rfwispan»  and  unspang,  a  value  that  is 
computed  in  more  than  one  way  is  denoted  {vi  |  ...  |  v»  },  where  Vj  represents  the  value 
derived  from  component  L  hhdtqde  ways  to  compute  a  value  are  maintained  to  ensure 
consistency  among  die  components. 


3.1^  Aggregate  Prototype 

Next,  a  proio^pe  (Hgure  3.5)  is  derived  (Hgure  3.1,  prototype  stq>)  trime  the  mqnessimi 
procednresddtoing  the  buffer  operations  are  transformed  into  functional  definitions.  This 
results  in  an  aggregeae  jnotot^^  which  is  a  refinonoit  of  the  aggregate  definitum.  For 
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Ijrpcbuf  «  Buf  €f  (int  x  ch*  x  ch*  x  ch*  x  (int  x  int)  x  lin«*) 
makebuf  <=  Buf(p.  t],  [],  [],  (0,0),  []) 

movB-righl^£<p,r,i.r,((p,<;p),tt)) 

1,  OdM(p,  qt*\in 

B»xe(p^  1,  /,  m  w,epf),  «> 

shoii»>char(Bttf(p,i./.r,<(p,9),tt)) 

iMa)|(ir(9-0)lhai‘Bl*ctetr[(p] 

neKt*lne(Ba£(p,t.l,r,((p,q>),tt))  ^ 

Ict4-(n^p06(tt))[(p]  -(ntp06(tt))[(p-l]  in 

Bu£(p>t>4, 1,  ,  r((4+ 1)»1 ,  ((p+  l,(y},  ts) 

foUrtlBt  Bu£(p,f,/,r,  (^,qt),ts)  0  <  ^  <  */ 

coMtmtrt  Bu£(p,(,/,r,  {i^,cp),ts)  0  <  (p  <  its 

caartraiBtBu£(p,(,/,r,(i^,(7),ts)  0<<7<#cs[(p] 


Hgme  3  Buffer  Prototype 


bstvity,  tbe  siq»s  have  been  omitted.  (The  steps  for  transfonnmg  movewlght  are  shown 
in  ^n>cadix  C)  As  widi  other  data  oansfonnations,  they  consist  of  a  number  of  purely 
mechanical  stqpsandafBW  insight  stqtsdiaticquireinjwit  from  die  designer.  Itisnotactually 
necessary  to  derive  translation  fnnctkms  that  are  computable.  Instead,  die  transfosmaticm 
process  makes  use  of  dion  in  syntactic  manipulations  to  obtain  computable  functions  for 
die  buffer  operations. 

Typically,  die  transfonnatkm  proceeds  ^ihexe:  (1)  die  bodies  of  die  old  operation 
and  spta  fimetion  are  expanded;  (2)  domain  knowtodge  about  die  data  iqiresentatimi  is 
apidied  to  simplify  die  bo^,  (3)  an  insi^  txep  is  apfdied  to  ‘Txndge”  the  old  and  new 
lepresentarionr,  (4)  additional  simplificatiem  stqis  are  q^lied;  and  (S)  die  qian  funetkm  is 
abstracted  from  die  body  of  the  operation.  The  insights  required  by  die  user  are  knowledge 
of  the  properties  of  die  domain  arid  the  underlying  semantic  modd,  and  knowledge  of  using 
traditional  transformations.  For  example,  transforming  movo-ri(;^  requites  knowledge 
abom  die  buffer  domain  dutt  adding  a  diaracter  to  die  buffer  dianges  die  point  of  editing, 
and  knowledge  about  die  underlying  model  of  sequences  that  a  sequence  is  equivalent  to 
die  list  formed  by  die  first  elem^  iqipended  to  the  rest  of  the  sequence.  The  traditional 
transformation  of  case  analysis  is  used  to  ciqiture  die  consttaiiits  on  die  buffer  domaiiL 

hi  the  prototype,  die  data  rquesmtation  is  sinqily  the  product  of  the  data  rqnesentations 
of  the  components.  All  congyments  are  updated  simultaneously.  The  makebuf  operation 
gtaierates  eadi  componmit  representation.  The  move-right  operatimi  increments  the  indme 
iqipropriatdy  for  each  component  (die  functions  hd  and  tl  return  the  first  elanent  and  tibe  rest 
ofaseqnenoe).  The  show-char  operation  returns  the  diatacter  at  die  poiiit  of  editing  in  die 
buffer  (die  function  last  returns  die  last  element  of  a  sequaice).  The  value  may  be  produced 
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Straetm  Buf :  BUF  ■:  Hract 

tjpcbuf  >  Buf  of  ((int  X  ch*)  x  (int  x  int*)) 
makebuf  Buf(0,  [],  0,  [D 

miM»<^ighfe(daiBuf(p,(,i,iiO) 

ctaeBufCp-t-l,  t,  (jtfnip(((/>])theBi-f  idwOi 

8hOMr-charCBtt£<p,i,i,a/))  ^ 

UpmOllnm  {ap) 
dKilp-l] 

next>iine(frMBu£(p,(,i,ii/))  <= 

>  lit Ci -!]))>«< then  6 
clMBu£(p*i-(M/[i]  -a/U  — 11),  it  i-i-1,  nl) 


Rgure  3.6:  Buffer  Implementatioii 


from  any  of  die  ifaree  leprejcatatioB^  these  toee  ahemarives  are  daioiBd  {  vi  |  V2  |  vs}, 
^^wreviis^lp-l]  andsoon.  Thisexteiisiaocc>u]dbeeaaQyiiiipleiiMfitedbysetectmgd)e 
first  altcnuttive  ao  diat  Ae  prototype  could  be  executed.  Midtqde  ways  to  compute  a  value 
ate  in  order  to  avoid  iftaiwg  infonnatian  that  may  fie  useful  in  !•*«•  tranrfnnnatififi  or 

analysis  siqis.  In  the  next-fine  operatUm,  die  positions  of  the  sunounding  newlines  are  used 
to  advance  to  die  next  line  for  the  Bufi  component  (drefonctionnipos  takes  a  sequence  of 
lines  and  returns  a  sequence  of  newline  positioos). 

Notice  diat  die  character  index  fior  die  Bufi  conqxxieat  has  fieen  transformed  to  use 
information  from  the  Buf  3  component,  udiere  it  is  eaaer  to  conqnite  newline  infiormation. 
The  fqpreaentation  of  each  component  is  availaUe  to  iqxlate  any  odier  component  lep- 
wjentation,  How  di^  are  used  provides  the  modvadon  for  the  final  iqpresentadon  dun 
fidlows. 

3.L6  Aggregate  Implementation 

fr  is  readily  apparent  diat  dtis  prototype  is  not  the  most  efficient  impleinaitadoo  becanse  of 
die  redundancy  in  the  data  and  die  operadoos.  Thefdlowingobservatioosareinade:  (l)It 
is  not  necessary  to  keep  die  dnee  alternatives  for  show-char,  so  one  of  diem  is  selected — as 
die  developer,  we  diooseitp-11,  and  makeacommitment  to  using  die  Buf  I  component  (2) 
The  ^oa  dements  of  die  Buf  2  component  /  and  r,  are  not  used  in  any  operations  to  compute 
the  data  elements  of  die  Bufi  component  forp,  so  diey  are  imnoved.  The  data  doiirats 
of  the  Buff  component  ts  tmd  (Pt  are  used  to  provide  newline  information  for  computing 
p  in  naxMns.  Th^  are  saved  in  dds  ^xicialiaBd  context  by  skating  (via  transformations) 
die  time  diat  foe  newline  positions  are  computed  from  access  to  generation  time.  Anew 
data  rqpresennaion  is  defi^  from  dds  process  of  making  commitmoits.  Hus  process  can 
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beconcqptnaBigdastmiCTii^ftomtfaeiTOtD^ypeiqwrirnittinntoaiiewiqMtiiCTti^ 
die  nuq;)  fonctioa  encqmilaies  die  insist  provided  tbe  naer  nidi  as  ooostndnts  oo  Ae 
ineissd  operatioiu  and  die  inqjiiemeiitadoo  efi&cieacy)  ooesidefatioiis. 

dieae  observadons  in  mind,  a  ipeciali7«1  inqilemenunion  (Rgme  3.6)  is  derived 

iMing  traiiffiniwiatMMi  iwrhnMp^  ^  nKuriti  f  twpwMMif  tinw  tht  npwiiiift  pnritinn* 

3.1,  in^ment  step).  This  aggregate  fnplemeauaitM  is  a  refinement  of  the 
ixoto^pe,  providing  an  ^'effideotTiniiilenieatadoa  of  die  dataQniie.  For  brevity,  the  slqis 
again  have  been  omitted.  PnfionumreisimprofvedlveliniinadngdmcoiiqpiitatioDfbrdie 
Buf 2  conqiooent,  and  oompudiig  neiriiiie  infionnadon  diiecdy  radier  than  maiiitaining  a 
sequence  of  lines  and  mapping  it  into  newline  posidoosiriiea  needed.  The  fiomer  is  an 
instance  of  leteariwg  components  from  die  datatype,  bridle  die  latter  is  an  instance  of  ihj/iwg 
computation  from  access  to  generation  time,  tedmiqnes  diat  are  described  in  [48, 7Q.  A 
part  of  die  derivation  that  illDStratBS  shifting  computation  is  shown  in  ^ipendix  D. 

The  new  apeciaKaed  representation  is  a  sequence  of  characters  wi&  an  index  for  the 
point  of  editing  and  a  sequence  of  newline  positions  widi  an  index  tracking  uriiich  line 
contains  die  point  of  editing.  The  makebuf  operation  now  generates  an  empty  buffer  and 
neadinecadie.  The  movaripht  operation  qpdates  the  nesriine  indar  when  crossing  over  a 
Ime  (die  pntficaie  nip  returns  true  sriien  its  argument  is  a  newline).  The  next-line  operation 
uses  die  newline  caciie  to  move  more  effidendy. 

The  oonatrahtts  have  been  refined  into  die  imidemeatations  of  the  operations  by  taking 
care  of  enor  handling  for  boundary  conditinns(tDaatis^  die  constraints).  They  ate  satisfied 
in  die  move-right  operation,  for  exanqde,  1^  returning  the  original  bnfier  if  an  attnoqit  is 
made  to  move  the  point  of  editing  past  die  boundary. 


3.2  Adapting  the  Buffer 

At  this  point,  die  initial  buffer  has  been  sucoessfiilly  implemented.  However;  it  often 
happens  diat  usen  desire  additional  functionality.  This  section  presents  a  mechanism  for 
introducing  diange  to  die  systBn(Hgure  3.1,  acfaytstqi).  Components  for  pages,  regions, 
and  s-expressions  are  introdnced  to  aihqit  the  core  system  conristing  of  die  components 
Buff,  Buf 2,  mid  Buf 3  (see  Rgnre  3.7).  The  di^lity  component,  Buf 41^,  is  added  in  the 
following  dutytec.  The  component,  Buf  i,  serves  as  a  nsefol  intermediate  for  relating  die 
component  for  s-cxpressions  to  the  existing  system.  Compatibility  nuq>s  are  rqnesented 
tty  arrows.  For  example,  an  arrow  from  Bttf2  to  Buf  1  rqicsents  die  compatibility  nuqi 
dun  adtes  an  object  of  type  Buf2  and  produces  an  obgect  of  type  Buf  1.  Aldiou^  Buf  is 

not  diown  in  the  figure,  it  does  not  mean  diat  we  most  start  all  over  again.  We  see  in  die 
exanqdes  that  foihm  how  the  existing  wodc  is  siqipleniented  vriien  adiqiting  die  buffer 
The  components  are  diooen  for  dnr  properties.  The  page  component  is  similar  to 
die  orighial  components  and  offers  anodier  view  of  die  buffer,  The  regioo  oooqxnent 
introdnces  something  new,  die  concqit  of  a  “mark.”  The  s-eaqnession  component  contains 
less  infonnation  about  die  buffer  than  die  original  conqxxients,  die  compatibility  map  frron 
dieooretoitismany-to-one.  The  goal  of  ddsexerciae  is  to  learn  how  die  meAod  handles 
a^qnation  and  acaB^  by  adding  components  under  a  variety  of  conditions. 
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Hgure3.7:  Buffer  Components 


3.2.1  Pages 

The  buffer  k  first  extended  to  openiB  on  pages  in  order  to  leam  hofw  Ae  Systran  is  adapted 
by  addbig  e  similar  kind  of  component,  alternatives  are  available,  and  the  cost  of 
adfing  a  new  coaqxneaL 

A  page  is  a  r^iao  of  text  delineated  by  a  qiedal  page  marker;  typically  die  **cootrcfi-L** 
charactec,  ^extend  die  buffer  signature  by  adding  the  ftdlowing  operations: 

bnokMaRHaeoa :  baf-»buf 
forwaRHMOe:  buf-^buf 
tehat-paga :  tmf  -«  int 

These  operations  allow  nioveaiem  to  die  previous  or  following  page,  and  provide  informa- 
tion  on  srfudi  page  the  point  of  editing  is  on.  For  these  opendoos,  we  view  die  buffer  as  a 
sequence  of  pages  widi  an  index  pointing  to  the  current  page. 

CaaipMHat  Buf^ :  BOF  s  struct 
type  page  «(ch-*tT 

typsbttf  m  Buf  af  (int  X  pagu*) 

backwaid-paQa(Bug(p<, »))  4=  BufCpf-i,  tp) 
forwaidpaoaCBuecpf.gi))  4s  Baf(pi4i,9) 

4nm^p$0Mfiat(pi,tp})  ^  pi 


Ibe  page  sqparators  are  inqilicit;  of  coarse,  an  alternative  rqaeseotation  is  possible  that 
keeps  die  page  sqierator  at  the  ad  of  each  page.  The  dxtioe  is  iq>  to  the  designer. 

Recall  that  the  original  qrstem  was  defined  using  an  annotated  signature  duu  q;iedfies 
how  to  inisgiBte  the  origiBaldiree  components  (Figure  3.2).  This  is  then  enriched  to  include 
die  compooeat  for  pages  by  ad^ng  di^  axioms: 

SBia«pfQj^(toiwanlpaQa(fr))  -  foiwinl>poQs^(pfo^(fr)) 

sBismpiuiitb)  mipf  P»o^)  prp|,(lofwardpaoi(*))  mapf  pro^(fbrwarcH)aoa(»)) 

arisaipteh^)  mspf  pre^B)  praih<*orwaidpogscfr))  mapf  pn^(torward*paoo(fr)) 

saisBipreMit)  mapf  pra((P)  ^  proh(*orwardpogo(»))  mapf  proj^(forwarel<paoe(fr)) 
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The  fim  axwm  qiedfiet  Ac  bdiavior  of  the  fbnranHMOB  operation  oo  the  data  aggregate 
in  terms  of  the  pay  component  where  It  was  defined.  The  remaining  axioms  ensure  that 
dm  iiysiem  remains  oonsisiBiit  after  the  operatioa  is  performed. 

Additionally,  the  axioms  for  die  orig^  operations  must  be  extended  to  ensure  oonsis- 
tency  of  the  new  oonqionent  when  an  <dd  operation  is  ^iplied.  For  mcanqde,  the  axioms  for 
move-fight  are  extended  witii, 

niamprpjiCe)  mapf  Pfoi^)  praftOnove-righKd))  mapf  pro^(move-rioht(6)). 

How  do  we  integrate  thiscomponent  with  ourpreviousiydevdopedbnfBer?  'Wbccxisider 
two  alternatives:  {\)  Merffngyttitii  the  wigtiud  system,  life  could  start  overly  integrating 
aU  of  die  conqwoentsagiun,  and  devdoping  a  new  prototype  and  implmnentation.  Wewill 
see  dua  mudi  of  the  inqriementations  fv  dm  operations  of  dm  existing  components  can  be 
renaed.  (2)  Translating  into  the  original  syaem.  We  could  choose  dm  rqpresentation  oi 
dm  otipnal  system  and  then  we  would  only  need  to  integrate  the  new  compramnt  widxxit 
modifying  dm  operations  of  dm  existing  tystem. 

Mcrgh^  with  the  Oriifoal  Syatcm.  In  order  to  merge  dm  new  component  with  the 
original  system,  first  we  must  define  dm  relationship  between  dm  component  and  dm 
orighmlbuffor,  sinoedmoontyooentisanewviewof  dmbufifcr.  This  is  accomplished  by 
defining  a  compatibility  nugi  diat  transhUBS  between  dm  new  conqmnent  and  one  of  dm 
previously  defined  conqiooeats.  Here  we  dmose  Bufi,  udmre  dm  buffer  was  rqnesented 
as  an  indm  maridng  dm  point  of  editing,  and  a  sequence  of  characters. 

map,^(Bu£i(ip,i))  ^  Bu£j^npagee(r[.^-l]),  char82paoa8(f)) 

We  miq>  Bofi  into  Buf^  by  counting  dm  number  of  page  nundasrs  preceding  dm  tect  index 
(dm  anxiliaiy  fonction,  npages,  returns  the  number  of  page  minkers  in  dm  text)  to  get 
dm  index  for  dm  page  in  s^iidi  the  poim  <rf  editing  occurs,  and  Ity  parang  dm  text  into  a 
sequence  of  pages  (using  GharB2page8).  ^  must  dmn  go  dnoogh  dm  process  of  integrating 
dm  components  to  obtain  a  prototype.  We  am  reuse  dm  implementations  for  dm  operations 
of  dm  existing  components  (fiiecdy. 

Additionally,  we  must  derive  a  new  implementation  for  eadi  page  operation  in  each  of 
dm  existing  components,  Buf  i,  Bufit  tmd  Bufs-  Wt  start  by  extmding  the  definitums  of 
Figure  3.4.  For  example,  dm  definition  for  forward-page  follows. 

local 

unapinCBufixf(p,f,^,V))  <=  {  niap,^(Buf i(p.  i))  I  Buf^Cpt,  ^p) } 

unapan'(Bu£'<ip,f./,r,((p,<7},tt,pf,4>))  ^ 

Bafi>v((#  i  jta  I  Pi  },  { t  I  4  i  ts  }>  tP> 

wha«Bttfi(jps,h)  -  mapi_,(Bu£j(/,  r)) 

wni9ati(pi,ii)  -  ma|3^,(Bu£3((<p,qp),  o)) 

li 

unapandorwar^paBo^  i w(p.«,p<.»)))  ^ 

k)mmtipuot^(unp§n(tiuftK^,  t,  pt,  ip))} 

unapaff(loiwaiti^aBe(Bttf^<p.<./.r.  {ip,ephts,pi,tp)))  ^ 
toiwaitiiMBiiKp(Mnapan'^u£'(p,  t,  i,  r,  {lp,ep),  tx,  pt,  tp))) 
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The  imnmediaiB  definition  for  (qypearing  after  die  k^word  in)  is  novel, 

sinoe  it  defines  how  die  newly  introdnoed  component  relates  to  an  established  one,  nan^ly, 
Bufi.  The  definition  for  tetwaid-pagediat  follows  it  is  similar  to  die  previous  definitions 
for  die  operations  of  Buf  i,  but  with  die  addition  Oi  die  Buf,  componeoL  For  example, 
conq[iarediii  definition  widi  die  one  in  Rgnre  3.4. 

We  mnst  also  deriveanewimptementationfor  each  operation  of  die  existingcongionents 
in  the  new  page  component  For  exaniple,  the  move-rH^  operation  (defined  in  Hgure  3.4) 
must  be  extended  to  define  die  operation  on  die  new  aggregate  that  includes  die  new  page 
component  in  terms  of  die  old  aggregate.  This  is  done  by  simply  adding  a  new  d^nition. 

local 

apan(Buf(p,i,/,r,  {tp,<a),ts))  <=  Buf^(p,  t,  l,  r,  (lp,ep),  ts,  pi,  tp) 

where  BuV(^,4>)  »  map,^,(Bu£i(p,  0) 

in 

mow-fiohf(apan(Buf(i».f.t.r.  {Ip,cp),m  ^ 
span(mov»-rlQhl(Btt£(p,  t,  /,  r,  {lp,cp),  »))) 

Wb  are  able  to  reuse  aU  of  die  old  definitions  of  die  core  system  (fireedy.  "We  are  able  to 
reme  parts  of  die  derivatian  as  well,  having  only  to  derive  new  implemiwtations  based  on 
the  above  definitions.  These  stqis  are  similar  to  dioae  done  in  the  core  system,  and  yield 
an  executable  protti^pe.  Pcrdreingdementationaqi,  wemi^choosetoqiecialuedie 
pages  in  a  similar  manner  as  we  spedaliaBd  lines,  hegting  a  sequoice  of  page  positions  and 
an  index  pointing  to  die  currem  page. 

TVaiMiatiiig  into  flie  Original  Syston.  When  translating  die  new  component  into  die 
original  system,  the  data  structure  and  operations  remain  undumged  in  die  prototyping 
sigi.  It  is  only  necessary  to  derive  a  new  implementation  for  each  page  gieration  into  die 
original  system.  For  example,  die  definition  for  forward-page  itdlows. 

toad 

un8pwi(Bu£i(p,i))  mapi^u£i(p,  t)) 

unspan'(Bu£'<p,r,i,r,<(p,<y),i»))  ^ 

I  P2  I  Fi}.  {<  1 I  ft}) 

whoncBufiCn.f^  -  mapi^,(Bu£i(/,  I)) 

andBu£i(^,0)  -  mapi^,(Bu£3«(p,<F),  o)) 

li 

unspKiotwnrd-paDe,<Bttfi<p.O))  ^  forwaid-page/un8pan(Bu£i<i>,  0)) 

unsimn^(foiwnrti-pSBe(huf*».<./.r.  (».q>).tt)))  ^ 
forwarti-paQe,(unepan'(Buf'(p,  r,  /,  r,  {ip,cp),  ts))) 

Oonqisre  this  definition  for  tranfiating  widi  die  one  givoi  previoosly  for  merging. 
There  am  die  same  number  of  definitions,  but  die  new  page  component  is  not  included 
in  die  aggr^ate.  Also  notice  that  a  new  definition  is  not  needed  for  any  of  die  existing 
operations,  suefa  as  rnovo-r^jW,  became  the  aggregate  rqiresentation  does  not  change.  For 
dteinqdemeniatinnstqi,  die  aggregate  can  be  gieciaKred  as  before. 
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Resions 

The  example  is  now  extended  to  provide  operatjons  that  mairipulatc  regions.  Recall  that 
die  previoiu  exaiiq>te  introduced  a  new  view  at  die  text  Iniffer  whidi  is  computed  via  a 
compadbili^  map  firom  one  of  die  previous  components.  A  region,  howevei;  introduces  a 
new  data  construct,  **maik,**  that  cannot  be  so  computed.  This  secdcm  idmitifies  how  this 
new  data  construct  interacts  widi  the  odier  components. 

A  region  is  a  portion  of  the  text  delineated  by  die  point  <rf  editing  and  a  special  maricer, 
called  die  molt. 

aeNnark:  buf>*buf 
exchange:  buf-»buf 
detete-region :  buf  buf 

The  operations  allow  one  to  set  the  mark  to  die  current  value  ofpoint,  exchange  die  values 
of  made  and  point,  and  to  ddete  the  text  betwem  mark  and  point  For  these  tqierations,  we 
view  die  buffer  as  simply  consisting  of  a  point  a  mark,  and  the  text 


CoaipoMBt  Buf r :  BUT  •  struct 

tjpc  buf  ■  Buf  at  (Int  x  int  x  ch*) 

aetwnark^f(p,M,i))  ^  Buf(p,  p,  t) 
exchangeCBuf(p,M,0)  ■«=  Buf(M,p,  0 

delete>region^uf(p,M,<))  ^  <mtbmp,mdaitm,pie 

Buf(/,  t  tW-11  #tC/-]) 


The  initialixation  of  die  made  is  handled  by  die  makebuf  operation  as  a  result  of  die  region 
component  being  integrated  with  die  existing  ^stem. 

A  compatibiliQr  mqi  between  tins  component  on  regions  and  one  of  die  existing  tmes 
is  easy  to  define.  ^dmoseBufi  since  its  fields  are  a  subset  of  Buf  r. 

mait.«i(Bufr(p,iR,0)  <=  Bufi(p,  0 

The  integration  is  simide.  For  example,  die  definition  for  set-mark  follows. 


load 

spin(BttfAp,»i,0)  ^ 

Bufix,(p',  f,p,m^(> 

wlMt«Bufi(p',iO  «  map^,(Buf,(p, «,  0) 
\jmpm(JBar(p,tJ,r,ifp,cp),ts,p,M,0}  ^ 

BufixXlf  I  I  fs  }>  { r  I  I  h  }.  m,  0 

where  Bufi(|i2,i^  -  inapa^i(huf2(/,r)) 

aBdBufi(p3,l!l)  -  map,^,(Buf9((^,q>).  o)) 

iu 

atfdDadkxr(«P«n(fr))  <=  span(set-inarlv<fr)) 
tinapanCiffdnhCh))  <=  8et-markixr<un8pan(fr)} 
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Since  jp  «id  r  are  idemical  to  die  coaqponeats  of  Bufi,  can  “share”  die  same  data  iq>- 

reamtttkm.  The  fimdefinidnndiensinqilifies,  since  aet-markixr  is  identical  to  aet-tnariy. 
This  is  a  qiedal  case  ^^lexe  (part  d)  die  cooqmdbili^  mi9  is  the  identity  funcdon.  The 
second  definition  also  singdifies  since  die  only  change  is  in  adding  the  mark.  The  additional 
data,  m,  is  added  widiout  affecting  aity  of  die  existing  components  since  it  is  "ordiQgDnal”  to 
die  odier  data  dements,  anMlce  Ae  previoiis  page  component  wfaidi  was  a  diffoent  **view** 
ofdiebiiffen 

Hus  also  singilifies  die  changes  to  the  existing  operations.  Fbrmunnple,  the  move-right 
operation  can  be  extraded  to  define  die  operation  on  die  new  aggregate  that  indudes  die 
new  r^ioo  component  in  terms  of  the  old  aggregate.  This  is  done  by  simply  adding  a  i»w 
definition.  However,  dus  definition  simplifies  to  die  crigmaldefinitimi  with  an  added  field 
that  is  simply  passed  along. 

local 

un8pan(Buf<p,i,i,r,((p,q>>,tt,p,ai.O)  ^ 

Buf'({p  I  »}./.**.  tt) 

whcKBafi(p,0  -  map,^,(Buf,(p,  ai,  *)) 

ia 

unapan(move-right*(a))  <=  move-right(ixi8pan(P)) 


The  point  of  dus  example  is,  there  is  a  mechanism  for  introducing  change  withoot 
moditying  the  oiiginai  system.  Even  if  we  only  want  to  add  an  operation  to  an  existing 
congwnait,  we  introdnoe  an  additional  component,  dion|d>^°»y  MlcaiticaliqirB- 

sentation  to  an  existing  one.  This  preserves  the  integrity  of  die  masting  system  and  also 
lecords  the  adquation.  Thmsfonnation  techniques  allow  one  to  ofMimize  die  aggregate  by 
sharing  representations. 

3J23  S-Ezpressioiis 

The  exangde  is  now  extended  to  provide  operatmos  to  mangmlate  s-mqnessuns,  nested 
parendiesiaed  expressions.  This  is  an  interesting  example  of  adapting  die  data  aggregate 
becanae  die  compatibility  nugi  between  die  aggregate  and  die  new  componmit  is  not  mie- 
toone,  amoe  infonnation  about  white  gwce  is  lost  t^ien  parsing  from  tma  to  s-eiqnessions. 
Here  an  operation  formoving  over  a  single  s-mqxnessioo  is  shown. 

moveaexp;  baf-^buf 

The  rqaeaeniatioo  of  die  component,  Buf  „  consists  of  a  pair  of  sequences  of  s- 
expressions,  to  the  left  and  right  of  die  point  of  editing.  Furdiennore  die  1^  sequmice 
is  reversed  so  dutt  bodi  sequences  can  be  reasoned  about  idaitically  (eg.,  as  stacks). 


CampoMnc  Bufc :  BOF  «  nract 

typcbof  ■  Buf  0r(8«Xp*  X  S«39*) 

move  seaqp^f(te,y»))  <=  Buf(a(Zr).  [hd(tr)]#n) 
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Hie  semantics  of  s-ejqnessioos  is  sensitive  to  die  context  in  n^udi  die  pomt  of  editing 
q^wars.  Analteniativeseinaiiticscouldbetoparsefnxnthebeffnningofthetnct  Howevo; 
n^iea  inside  a  nested  s-expiession.  move-«exp  is  only  qiplicable  to  s-mqnessicMis  at  that 
kvd  of  nesting,  so  infocmatioa  about  s-expressions  in  the  enclosing  nesting  levels  is  not 
needed.  If  operadons  to  ascrad  and  destxnd  nesting  levels  were  to  be  defined,  then  a 
diflfeienttqneaentation  for  die  type  would  be  lequhcd. 

This  component  is  linked  to  the  core  systmn  duou^  an  intermediate  compaamt  Buf 
(for  oonvmiience)  that  has  no  operatims.  Ibe  conqxment  rqnesents  the  buffer  as  a  pair 
of  sequences  of  chaiaders  to  die  kft  and  right  of  die  point  of  editing.  Like  Buf „  the  left 
sequmioe  is  is  reversed  so  dut  both  sequmces  can  be  reastmed  about  idmitically. 


CoaipoMBt  Bufi :  BUF  s  nraet 
Ijpc  buf  ■  Buf  of  (ch*  X  ch*) 


The  text  is  parsed  into  a  sequmice  of  s-exprmsions,  starting  firom  the  point  of  editing,  and 
proceeding  in  both  dtrections. 


local 

parse  ^  ta[].[] 

I  oonB(<i,x) .  if  a  €  [IV.-V,  ‘0’..‘9*D  Am  oon8«sexp),  paraaCparse-anOc))) 
dK  tf o  « *C  tboi  oon8({Mip),  pareeicpaise-sexpOc))) 
dwfro«Ttkca[] 
dKparseOd 


parse-an  lb[].[] 

I  oonB(a,x) .  if  a  €  (i*a\.*z%  *0'..*9*p  thai  parse-an(x)  dtae  oons(a,  x) 


parsa-eaxp  ^  error 

I  oon8(a,z).ifa«*)*ttCBx 

dw  if  a  >  T  tbcB  parBe^xp(parse-6exp(x)) 
ctacparseWpCx) 


mapk_«(BufKdia))  Buf/par8a(M),  parsefa)) 


Tbe  operation  parse  produces  a  sequence  of  s-ejqnessioo  tokens  fipom  text  This  is  easy  to 
definensingdieMLnotationfordefiningafimctionnsingpattems,fti/Mir.e;9i  |  pat.ejp.  If 
die  aigoment  is  die  em]^  list  dien  the  em|^  list  is  returned.  Iftfaeaiguinoitisanonemp^ 
list  dien  it  is  parsed  depending  on  triiedier  it  is  an  a^dianumeric  symbol  or  an  mnbed^ 
s-eiqpresriao.  This  is  a  many-to-one  ftmedon  since  informadon  about  white  space  and 
die  text  of  die  atomic  symbols  is  lost  It  makes  use  of  two  auxiliary  functions,  parse-an 
witi^  sk^M  over  die  current  aljdiannmerk  symbd  and  parse-sexp  w^ich  skips  over  nested 
S'expcmsioos. 

The  conqxment  Buf  j  in  turn  is  linked  to  Buf  2,  diey  are  siinilar  in  rqnesendng  die  buffa 
as  a  pair  of  sequences  of  diaracters  except  diat  die  left  sequence  of  (me  is  the  reverse  of  the 

OCDbI; 


mapu2(^f<<d>«))  <=  BufafravCw),  n) 
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The  9-«]qiiessioo  compoomt  is  now  integrated  widi  the  buffer.  ^  nuunine  here  the 
first  and  most  important  stage — translating  into  Buf  ,•  which  ‘Tiridges’*  the  gi^  between 
s-ejqnessioiisttidtacL  Starting  with  the  standard  data  transformation  form, 

map;^(mov»<expCBuf iOw,  n)))  move-6exp^(map;_^(Bu£i(m,  n))), 

and  assuming  we  have  a  definition  for  unparee,  we  are  able  to  use  simple  syntactic  manipu- 
ladons  (such  as  folding  or  unfolding  or  rewriting  equals  for  equals  using  dcnnain  knowledge 
about  sequences)  to  get  die  expressum  into  die  form: 

mov»-eexpCBu£i^,ii))  lctxsat(z#tisexp(in))  «  miB 

Bu£j(ti8exp(m),  r^)#ji) 

tIsexpCx)  unparseCKparseOc))) 

For  notational  cmvoiience,  we  introduce  **x  sat  eq.**  where  the  variable,  x  satisfies  the 
equation  (cf.  unification  in  Rcdlog). 

This  definitkm  is  not  yet  complete,  since  we  did  iK)t  say  how  to  cmnpute  unparse.  Even 
if  we  (fid  know  how  to  ccxnpute  unparse,  we  would  not  te  guaranteed  of  getting  back  the 
original  text  However,  we  do  not  want  a  general  definid<m  for  tuqiarse,  only  one  where  it 
appean  in  die  particular  contract  ttfdsexp  above. 

Dcrivinf  tisexp.  A  functional  definitkxi  is  derived  for  tisexp  using  expression  proce¬ 
dures.  We  examine  the  case  when  we  ipply  the  definiticm  to  a  non-empty  list  Hrstcmnpose 
parse  with  d  and  simplify. 

tl(por8e(oon8(a,x)))  tt a  €  [|V..V,  *0’..*9’p  then  parseCparse-anCx)) 

dK  ifa  a  T  titea  parseCparse-sexpCx)) 
dMifa-TthoiE] 

dM  tKparseCc)) 

Next  compose  die  raqnession  widi  unparse  and  simplify,  using  die  simplificatiem  rule 
unparse<pGsse(x))  «  x  We  justify  ^  rule  by  having  iraparse  consult  an  “oracle,”  for 
instance,  a  global  variable  vdiere  parse  has  copied  its  argumrait  Later  we  see  diat  we  no 
hmger  need  either  of  these  operations,  so  we  do  not  need  to  actually  use  the  made. 

unparse(lKperse(oon8(a,x))))  •«=  if  a  €  [|V..*z’,  *0’..*9’p  thee  paise-anOc) 

dae  ifa  «  T  thai  PCtfse-sexpCx) 

dMira-‘)’thcn[] 

die  iMparseCKparseCz))) 

Abstract  unparse(tKparse(x)))  into  tIsexpOc). 

tleexp(oon6(a,x))  ^  ira€(|V..'z’,*0’..*9’pttaipar8e’an(x) 

dK  ifa  a  *C  Am  parse-sexpCx) 

dwtfaayifcaiE] 

dseteexpCx) 

It  is  never  actually  necessary  to  compute  unparse. 

Since  the  f-raqnession  component  does  ixit  have  ccxnplete  infbrmatUm,  it  must  be 
translaied,  However,  we  could  have  chosrai  to  cache  die  s-raqnession  positions  as  we  did 
die  nendine  positions,  but  dns  would  be  mudi  more  complicated.  So  we  chose  a  quick 
imegradon  process  for  the  purposes  of  diis  example,  trading  off  dus  optimizadexL 


3J.  Summary 


57 


33  Summary 

Putting  everything  together  ftom  the  three  examples,  the  process  of  merging  the  three 
additional  components  with  the  original  system  yields  the  new  prototype  in  Hgure  3.8. 

The  data  stnumne  contains  the  fields  from  the  original  tiq)le  of  the  first  three  compo¬ 
nents  augmoited  with  all  the  fields  from  the  page  component,  cmly  die  mark  field  from  the 
regicHi  component  (since  the  other  fields  are  Aqilicates),  and  no  fidds  from  the  s-expression 
cmnptment  (since  we  decided  on  an  expedient  integration).  The  operations  of  die  original 
system  have  been  modified  to  operate  on  the  new  data  representation.  Alternative  imple¬ 
mentations  of  the  operations  of  the  new  components  have  been  derived  for  the  aggregate. 
The  results  of  this  example  are  inteipretod  in  Chapter  5  after  we  complete  the  example  by 
adding  a  display  in  the  following  chapter. 
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StrnctBre  :  BUF  s  struct 

Qrpebuf  =  Bu£  of 

(intxch*  — pointed  editing  and  text  in  die  twffer 

xch'xch*  — cbacactecs  to  the  left  and  right  of  pdnt 

x(intxint)  — die  line  and  duracter  positioned  point 

X  line*  — lines  in  die  buffer 

X  intxpage*  — enneot  page  and  pages  in  die  buffer 

X  int)  —positioa  of  the  marie 

makebuf  v--  Buf(p,  tl,  [1,  [1.  (0,0),  ti,o,  [J,  0) 

move-right(Bu£(p,t,/,r,  {lp,q>),ts,pi,9,m))  c 

s  if(g>a«tr[(p])dien^-i-l,0dse(p,(;p4-l, 
pf  s  iftOl  «*L*tliaipi4-ldsepfin 
Buf(/>+ 1,  t,  /#  [hd(r)],  tkr),  {lp\q>‘),  ts,  pi\  tp,  m) 

showKdiar(Bu£(p,t,/,r,(4i,<7},tf,pi,tP.m))  ^ 

|last(0|(ir(4i«0)t]ien^*cisett[4’] 

next-line(Bu£(p,t,/,r,((p,<9i},tr,jri,9>,m))  •<= 

ktd  =  (nlpos(tf))t4»] -(nlp08(tt))[4»-l], 

<£  >  npages(t[p4p  •!•</)])  in 

Bat(p*d,  t,  ts,pi*(f,  tp,  m) 

1brward-page(Bu£(p,f,/,r,  (ilp, <7).  ts,|d, 41,01))  «= 

ktd  =  (paaepo8«p))[pn -(paQepos(9>))ipi-i], 

df  s  numnKtC/'-^+<0])in 

Bu£(p  +  ri,  t,  /#r[-ri] ,  r[(ri+ 1)-1 ,  {lp+<f,cp),  ts,  pi+ 1,  tp,  m) 

set-maiHBuf(p,t,l,r,{lp,cp),ts,pi,qf,m)}  ^ 

Bu£(p,  t,  I,  r,  {tp,<p),  ts,  pi,  p,  p) 

move-sexp(Bu£(p,/,/,r,  {lp,cp),ts,pi,tp,my) 
ktxsatx@tisexp(rev(/))  s  rev(0, 
r  =  tlsexp(rev(0),>^  »  re^)©r, 

p'  =  #1'. 

(p'  s  i;p-i>numnKt[pw''l)> 

pi'  s  pf-i-npage^rCp^M)in 
Bu£(p',  t,  V,  r*,  (lp',q>),  ts,  pi',  tp,  m) 


Figure  3.8:  Adapted  Bufifer  Prototype 


Chapter  4 

Reuse  and  Customization:  Deriving  an 
Interactive  Display-Editor 


In  the  previous  chapter  we  constructed  a  bu£Ea  from  components  and  then  added  additicmal 
components  to  adapt  the  buffer.  We  saw  that  cmnpcments  can  implemoit  parts  of  a  datatype 
and  that  the  tiansfonnatimi  methods  enabled  us  to  integrate  the  parts  into  an  aggregate 
data  structure  and  to  peifonn  fiirdier  optimizadoas.  Now  we  change  our  focus  to  the 
module  level  and  use  the  buffer  as  a  part  of  a  larger  display-editor  system.  We  see  how 
transformation  techniques  are  ^lied  to  hierarchically  structured  module  ^sterns,  where 
modules  are  defined  in  terms  of  other  modules.  The  buffer  data^pe  that  has  been  previously 
developed  is  reused  and  custtnnized  in  the  ctmtext  of  a  larger  intoactive  di^lay-editor. 
Transformations  are  used  for  adiq)ting  data  representatitms  and  abstract  interfaces,  and  for 
cytimizations. 

The  display  editor  is  built  in  a  series  of  stages.  Hrst  we  go  through  the  exercise  of 
adding  a  screen  for  displaying  the  buffer  to  the  uso’.  Thei  we  generalize  the  system  to 
allow  multiple  buffers.  Hnally,  we  introduce  windows  to  di^lay  more  than  one  buffer  on 
the  screen  at  a  time.  This  module  hioarchy  is  summarized  at  the  end  of  the  chapter  in 
Figure  4.2. 

These  modules  were  chosen  for  their  pr(q)erties.  The  screen  module  is  introduced 
indq)endent  of  the  buffer  and  displays  smne  **di^layable  object”  We  then  d^e  a  display 
view  for  the  buffer  as  the  screen’s  displayable  object  and  integrate  it  with  the  original 
buffer  proto^pe.  Once  integraticm  is  achieved,  additicmal  (^timization  techniques  are 
applied  to  take  advantage  of  dm  close  correspondence  between  the  buffer  and  the  screen. 
Tim  multiple-buffers  module  demonstrates  how  module  interfaces  are  ad^ted  by  creating 
a  new  module  tiiat  includes  die  old  one,  and  then  propagating  the  operations  using  data 
transformatitm  techniques.  The  multiple-windows  module  also  demonstrates  how  module 
interfaces  are  adapted.  In  additicm  to  the  mediod  used  in  the  multiple-buffers  module, 
a  mote  syndietic  approach  is  taken  where  the  desired  intoface  is  exposed  ftom  existing 
information. 
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4.1  Single-Buffer  Single-Window  Display 

This  sectkn  begins  by  extending  die  text-buffer  example  to  provide  oii^ut  of  the  buffer  on  a 
simplesciten.  Rrst  the  data  structures  are  introduced  and  then  transfonnations  are  presented 
to  integrate  diem.  The  first  dam  structure  introduced  is  the  scivendiatdiqdays  a  porticm  of 
a  **display  plane,”  some  planer  tqnesentadon  of  a  di^layable  object  The  display  plane  is 
then  designed,  and  d^ines  how  sndi  an  object  is  rqnesented  tm  a  saemt  The  d^niticm 
of  "object”  is  left  cqien  at  diis  time,  as  long  as  an  object  meets  the  requirements  of  die 
diqilay  plane,  it  can  be  shown  cm  the  screen.  Hnally  a  dt^/dy-edtftir  structure  is  designed 
as  the  ti^le  of  the  buffer  and  the  screen  and  an  origin  wl^h  pins  the  screen  to  the  buffer; 
tins  definidtm  is  influenced  by  [88].  The  buffer  must  dien  be  defined  as  dm  displayable 
object  in  die  screen  by  creating  a  new  buffer  cmnpaoent  diat  meets  the  requiranents  of  the 
displayplane.  The  first  transformation  dien  integrates  tins  new  compmimit  with  the  origmal 
buffer  This  is  dmie  using  techniques  develc^ied  in  die  previous  cluqitBr.  Then  subsequent 
transformations  c^dmire  the  display  editor  by  more  closely  "coupling”  the  buffer  and  the 
screen. 


4.1.1  Defining  the  Display  Editor 

A  screen  is  a  bounded  portkm  of  some  diqilayabie  object  and  a  cursor  position  that  points 
at  some  portion  of  die  object  Let  os  call  the  di^layable  rqpresentatitm  of  the  object  a 
"display  plane.”  We  dien  define  die  screen  as  a  bounded  portion  of  die  unbounded  display 
planea^acursorpositianidaitifyingdiepointofediting.  This  enables  us  to  use  the  screen 
u>  display  a  variety  of  objects. 

agUtnc  SCREEN  «  dg 

tJpcscrMn 
type  origin 

diap-to-acraen :  origin  x  disp  — » screon 
poBcjr:  origin  x  disp  -» origin 


The  operation  (fsp-to-&'rBen  creates  a  screen  from  a  portion  of  die  di^lay  plane.  Tim 
portion  of  dm  diqilay  plai  e  to  show  in  dm  scremi  is  marked  by  dm  origin,  which  effectively 
piiu  the  screoi  to  dm  buffet  The  operation  policy  picks  an  origin  for  dm  display  plane. 

Before  defining  the  implementation  of  dm  screen,  we  define  the  display  plane.  Adi^lay 
plane  provides  a  two  dimensional  representation  of  an  object  diat  is  a  useful  concept  for 
m^qnng  differrot  kinds  of  objects  into  a  screen.  use  a  simple  definititm  where  die 
omtents  of  the  two  dimmisional  representation  are  characters. 

SigaataicDiSPsii^ 
type  disp 

content :  disp  — » planepos  -*  ch 
current :  disp  — » planepos 


4.1 .  Single-Buffer  Single-Window  Di^lay 
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The  cont^  openttimi  takes  a  display  plane  and  returns  a  functioD  diat  given  a  di^lay  plane 
position,  returns  die  character  at  diat  posidtm,  and  die  current  operadtHi  returns  ^  di^lay 
plane  poddon  of  die  point  of  editing.  Wt  ddcr  the  implonentadtMi  of  the  display  plaM  at 
diis  time,  until  a  later  time  when  we  have  an  object  to  display. 

The  Screen  is  represented  by  a  cursor  posititm  and  the  **tq)pearance**  of  die  object 
diat  is  diqilayed.  The  appearance  is  a  fimctitHi  diat  mqis  a  posititm  in  the  scremi  into  die 
conespmding  character  in  the  display.  Associated  widi  the  screen  is  seme  internal  state, 
height  and  width  that  denote  the  hdgfat  in  lines  and  widdi  in  characters  of  the  physical 
screra.  The  area  bounded  by  height  and  width  is  screensurface. 


Stracture  Screen :  SCREEN  s  struct 

tm  screen  a  Screen  of  cursor  x  (cursor  — » ch) 
tjP*  cursor  >  n  x  n 
«JP«  origin  a  n  x  n 

valheighta20 

valwidthaSO 

valscreensurhKiea  i„height  x 

proiect(r,cX/J)  •«=  {^+f.  c+7> 

origin8(4)  {(r,c)  |current(<0€praject(r,c)[|8aeensurface|]} 

di8p-to^een(o,4)  ^  lctpaoontant(4)oprQject(o) 

sad  c  sat  curr^d)  a  project(oXc) 
sad  spaces  »  {MJ :  N .  *sp’)  in 
Screen(c,  (jp0ccs®j7)\screensurfac8) 

poli^o,4)  •«s  iro€origins(<0thcaoclse(x|z€origins(4)) 

CBBstrataf  Screen(c,a)  a=>  c  €  screensurfece 
coartntnt  Screen(c,a)  ^  domdn(a)  a  screensurface 

cad 


The  screen  operadmis  are  defined  in  terms  of  die  local  cqierations  project  and  origins. 

project:  origin  — » cursor  planepos 

origins  :  <tisp  ^origin) 


The  project  operation  prefects  die  cursor  position  relative  to  die  origin  to  yield  a  display 
plane  position.  The  operation  origins  cmnputes  a  set  possible  boxes  of  dre  size  of  the 
screen  (rqnesrated  by  the  top-left  coordinates)  that  cemtain  the  point  of  editing  in  the 
display  plane  (/^(origin)  is  the  set  of  all  origins). 

The  cfisp-to-screen  operation  computes  a  screoi  based  mi  die  origin  and  die  display 
plane.  Notice  the  equational  nature  of  the  cmnputatimi  for  the  cursor  c,  whme  it  is 
computed  such  diat  it  satisfies  (sat)  an  equatitm.  Tlw  iqipearance  is  cmistructed  using 
content  to  convert  the  display  plane  into  a  ftmetum  that  takes  a  display  plane  position 
and  returns  die  charactor  at  ^  position.  In  die  qipearance  functimu  die  display  plane 
is  first  projected  widi  the  origin  to  yield  die  display-plaiw  positiexL  This  establi^es  the 
top  and  1^  boundaries  of  die  screen.  Thoi  die  resdting  display  plane  is  restricted  to  the 
saemisurface  to  establish  die  bottom  and  right  boundaries  of  the  screen.  (The  domain 
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buf 

origin 

screen 


j 


Figure  4.1:  The  Display  Editor 


restrictkm  operator,  \  maps  a  functitm  f,  and  a  subset  of  dnnmits,  5,  to  a  functitm  which 
agrees  with  f  <m  the  set  5  and  is  elsewhere  undefined.)  Spaces  are  filled  into  places  in  the 
scremi  that  do  not  correspond  to  displayable  text  (The  fiinctumal  overriding  operator,  0 
mi^  a  pair  of  fiincticms  to  (me  that  agrees  with  the  first  everywhere  exc^t  on  the  domain 
of  the  secootL)  The  policy  (>perati(m  returns  an  appnipriate  origin.  It  uses  the  old  value  if 
possible  to  minimire  screen  update,  otherwise  a  new  one  is  picked  (eg.,  such  that  point  is 
in  the  middle  of  the  screen). 

A  display  editor  is  now  constructed  m  terms  of  the  buffer  (devel(>ped  in  the  previous 
cluster),  die  screen  and  the  origin. 


SgnatareOEDs  df 
Qrpeded 

ded-make :  ded 

ded-op :  (buf  — *  buf)  — ►  ded  — ►  ded 

Old 

The  display-editor  data  representatkm  is  defined  as  a  tiqile  ccmsisting  of  die  buffer, 
origin,  and  scremi  (see  Hgure  4.1).  The  origin  pins  the  screen  to  the  buffer  and  is  the 
positicm  of  the  top-left  comer  of  the  screen  relative  to  the  buffer. 

Structure  DEd :  DED  s  struct 

structure  Buf  •  Buf,  Screen  «  Screen 
Qrpe  ded  «  OEd  of  (buf  x  origin  x  screen) 

ded-makeO  <=  ktb'«makebufando'>{0, 0)in 
let  y  «  di8p-to-8Creen(o',  60  in 
DEd(6',  o',  jO 

ded-op(c)(pEd(6,o,r))  ■<=  let  6' «  c(b)  in 

leto'Bpolicy(o,  60  in 

let  s'  >  di8p-to-8creen(o',  60  in 
DEd(6',  o',  jO 

CQnstraiBtDEd(6,o,r)  5  »  di^to-8creen(o,  6) 


4J.  SingU'Bui^Sii^U-'WUidofW Display 
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The  ded-op  command  qqplies  the  buffer  opentioas  (delete,  ineert,  move-right,  move-left, 
and  next-line)  m  the  iNiffer  and  tq^KhUBS  the  screen  and  origin  qppropriatdy.  The  invariant 
between  die  buffer  and  the  ori^  and  screen  is  recorded.  It  can  be  easily  chedced  that  each 
operation  defined  on  die  display  editor  preserves  diis  invariant 

This  defiirition  of  die  scre^  is  not  quite  correct  however.  We  are  not  able  to  tqiply 
dtep-to-screon  or  policy  to  an  ^dyect  o£  ^pe  buf ,  it  requires  an  object  of  type  disp.  ]fe 
order  for  this  definition  to  be  c^nect  we  must  make  the  connection  between  the  text  buffer 
and  die  diqilay  plane.  ' 

4.1^  Defining  Buffer  as  a  Displayable  Object 

Using  die  methodcdogy  developed  in  die  previoos  chiqpter,  we  define  a  new  buffer  compo¬ 
nent  diat  is  a  displayable  object  that  is,  it  implements  die  two  qieratimis  necessary  for  it 
to  be  displayed  on  the  screen.  The  representation  dl  diis  view  of  the  buffer  crmsists  of  a 
sequoxx  of  lines  above  the  point  of  editing,  die  sequmice  of  riiaracters  to  die  1^  (d  point 
(on  die  line  point  is  on),  die  sequmice  of  characters  to  die  rig)it  of  pmnt  and  d»  sequence 
of  lines  below  point  The  lines  operatkm  returns  die  contents  of  die  display  plane  as  a 
single  sequence  of  lines  (of  arbitrary  lengdi).  The  point  of  editing  in  die  di^lay  plane  is 
ejqxesaed  as  a  line  and  character  porititm.  It  can  be  diou^t  of  as  a  two-dimenaonal  view 
of  die  buffet 

Compotat  Buf :  oiSP  s  stract 

type  disp  «  Buf  of  (line*  x  ch*  x  ch*  x  line*) 
typeplanepos  ■  n  x  n 

local 

line8(Buf(a,ld,nt,h))  <=  a#[U#rd]#fr 

io 

oontsntC^K^c)  ^  line8(<0(rKc] 
currenl(Buf(a,U,rd,6))  •<=  (l-ffo,  fU) 

end 

end 

Ihe  representation  for  die  new  oomptment  must  berectmciled  with  the  previous 

buffer  representation;  this  new  display  view  must  be  merged  with  the  origmal  buffer  before 
we  are  abk  to  use  it  A  compatibility  mei  between  this  display  view  and  one  of  the  previous 
represratationsisneededtorelated^newtypewiditlieprevioosptototypebuffet  Hereitis 
natural  to  choose  Buf  2  as  die  comptmmt  to  relate  die  die>lsy  with,  because  the  compatibility 
nup  is  easily  writtnt 

map4i^2(uu£a^(o>  rd.  h))  <=  Buf 2<Une»-to-char8(a  #  [U]),  lines-to-chars([n/]  #  b)) 

There  are  a  number  of  ways  to  accomplish  die  integration  (see  Section  3.2.1).  Oneway 
is  to  merge  the  new  di^lay  componmit  with  die  components  of  the  original  system.  This 
invdves  rederiving  all  die  tmfferoperatuxis  to  include  the  new  Buf  4fi),repiesentati(nL  This 
rederivatkm  is  not  as  difficult  as  the  origmal  derivation  since  the  type  is  being  adapted  and 
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mudi  of  tbederivatknstracture  can  be  leased.  Another  way  is  to  keq)  die  previous  buffer 
iqnesoitatioii,  and  translate  the  diqday  operations  into  this  representation.  Since 

Buf^  is  similar  to  Buf 2  dds  way  isdiosea  fordie  sakeof  mqpedieacy. 

Tteoperaticms  to  be  transfiormedare  lines,  oontant,  and  current  Looking  at  the  comma 
of  where  die  opexadoos  are  used,  it  is  observed  that  lines  only  occurs  widun  die  context 
die  definition  of  content  Radier  than  computing  the  entire  set  of  lines  widiin  the  buffer 
and  then  taking  only  one  diaiacter,  we  combine  these  operations  to  obtain  an  optimized 
version  diat  accesses  die  character  direcdy;  we  do  dus  by  transforming  content,  instead  of 
Hnes.  get  the  following  implmnentations: 

oonl0nt(Bufi(p,t,i,ii/)Xr,e)  c 
current(Buf.-(p,r,t,ji/»  <=  (i,  p  -  H/[i  - 1]) 


Since  the  Hnes  toleration  is  no  longer  referenced,  it  is  released  from  the  module.  Widi 
diese  new  implementations  a  single  representatitm  for  buffer  is  again  derived  and  this 
prototype  is  used  widi  the  simple  di^lay. 


4.13  Caching  the  Screen 

Now  that  we  have  integrated  the  di^lay  editor,  we  turn  mir  attentitm  to  <o>timizations. 
Rathm- than  iqidate  the  entire  screen  after  each  buffer  operatitm  as  the  prototype  just  defined 
does,  we  seek  to  incremmitally  update  the  screen.  This  is  accomplished  by  qiedalizing  die 
buffer  and  screen  operations  in  the  context  of  the  diioilay  editor.  Here  diey  are  specialized 
for  (0>dmizing  die  screen  performance.  One  virtual  model  of  a  screen  is  a  matrix  cache; 
this  cache  is  updated  firom  the  di^lay-^tor  data  structure.  Special  built-in  low-level 
operations  iqxlate  the  physical  screen  of  the  terminal  firom  the  cache.  Operatirms  for 
tqpdating  a  character  or  liM  in  die  cache,  and  for  effidem  scrolling  ate  provided.  (These 
a^odier  hardware  ciyabilities  ate  recorded  for  machines  using  die  UNIX  operating  systmn 
in  the  terminal  mqiability  data  base,  *ieimci^”)- 

In  the  display  editor,  diete  is,  in  effect,  a  narrow  communication  band  betwemi  die 
buffer  and  die  screen.  Vh  want  to  increase  die  amount  of  communicatimi  betwemi  die 
buffer  and  die  screen.  Radier  dum  performing  a  buffer  operation  (which  may  be  highly 
localized)  and  then  mqiping  die  entire  buffer  to  die  screen  (a  global  operation),  we  wish 
to  localize  the  changes  to  the  screen  whenever  possible  (utilizing  the  amiabilities  of  the 
terminal  to  improve  performance). 

Incremental  Update  of  the  Screen,  ^express  the  optimization  of  incrmnentally  updat¬ 
ing  the  scremi  in  terms  of  die  data  transformatimi  schmne.  We  can  diink  of  die  bttffer  and 
screen  as  different  "views,”  where  the  dsp-to-acreen  operaticm  is  the  compatibility  map 
dutnumis  buffers  into  scremis.  Then  our  task  is  to  transform  a  buffer  tqieration,  move-right, 
for  example,  firom  operating  on  buffers  to  operating  on  screens. 

A  new  implmnmitation  for  die  move-right  operation  is  derived  by  first  specializing 
deciop  for  dus  command. 
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mov8-right'(d}  <=  ded^move-rtgntXd) 
Unfokliiigded-cp  yields: 


move-rloht'o>Ed(b,o,s))  <=  kti'm  move-right(^)  In 

kti/mpoUcyCo,  y)lm 

Ici/><88p4o4craen(o',  ^in 
DBd(6',  </, 

The  focus  of  diis  example  is  ooq)edalizmg  the  screen.  Here  die  screen  ^ipearance  is 
computed  by  dbp-to-scrBen  eadi  time  the  move-fight  command  is  invdted.  The  argument 
s,  the  old  value  of  the  screen  is  never  used.  But  we  know  that  if  die  cursor  does  not  move 
off  die  screen,  dim  die  new  qipearance  trf  die  screen  is  exacdy  die  same  as  the  old  value 
so  it  need  not  be  recomputed.  In  order  to  express  the  updated  scremi  in  terms  of  its  old 
value,  we  look  at  the  definition  for  iqidating  the  screoi.  The  old  value  is  defined  in  terms 
of  content(b)  while  die  new  value  is  defined  in  terms  of  content(move-right(b)).  So,  if 
we  are  able  to  reason  about  content(move-right(b))  and  express  it  in  terms  of  content(b), 
dien  we  can  reuse  the  dd  value  of  die  scrnm. 

The  steps  to  accomplish  this  follow.  The  portion  of  movenlght'  where  s'  is  defined  is 
shown  where  disp-to-screen  is  unfolded. 

/  »  kc  p  •  oontant(i/)  o  projeci(0O 

and  e  am  current(IO  >  projoct(oO(c) 

Mad  graces  la 

Serene,  (4gMice>0p)\screensurface) 

The  cursor  c  will  always  change  while  the  qipearance  may  stay  the  same  in  some  cases  so 
again  the  attention  is  focused  on  die  qipearance,  a  partial  definititm  of  which  follows. 

oontenKhO  o  praj6Ct(oO 

The  definititms  of  1/  and  o'  are  expanded. 

ooment(tnove-righKl^})opraject(policy(o,  y)) 

Reasoning  about  the  definition  of  move-right  widiin  die  context  of  content  reveals  that  the 
contents  of  the  buffer  does  not  change. 

oontent(fr)  o  proiect(poiicy(<7,  hO) 

The  definition  of  policy  is  next  unfolded  tti  reveal  a  condititmal  expressimi  ttdiich  is  brought 
to  the  outside  of  die  expressiocL 

if  o  €  origin8(ti0  that  oontent(h)  o  projec^a)  dK  content(h)  o  prcject(o') 

This  reveals  the  mqnession  **content(h)  o  proJecKo)**  vdiich  is  meaedy  the  value  of  the  old 
screen  qipearaiice.  The  value  of  the  screen  is  cadied  and  used  in  this  case. 
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if  o  €  origins(^0  «  dw  oontenK^)  o  prpjedCoO 

By  xeasomng  about  content(move’right(b)),  we  find  duu  under  certain  conditioiis,  no 
change  is  necessaiy  to  die  qipearanoe  of  die  screen  ao  that  we  save  the  expense  (rf  iqxiatmg 
it  A  similar  ar^unrat  holds  for  move-left  and  next-bie. 

New  imptementations  for  die  insert  and  delete  operatkxis  can  also  be  derived  (but  are 
not  shown  here)  by  qiecializingded-op  for  dris  command.  Unlike  move-rigfit  the  contrat  of 
die  scremi  will  dumge,  but  die  diange  is  bij^  localized,  widi  rnudi  of  die  screen  remaining 
die  same.  For  example, 'i^mi  a  character  diat  is  not  a  newline  is  inserted,  everything  above 
and  below  die  cnrtmit  line  remains  the  same.  Only  the  cuneot  line  need  be  updated.  When 
a  newline  is  inserted,  everything  above  the  current  line  stays  die  same,  while  die  lines  below 
die  current  line  ate  scrolled  down  by  one.  These  observatims  ate  made  in  teastming  about 
content(in8ert(cJ>)).  By  judicioos  manipulation,  an  implementation  for  the  qperadon  can 
be  derived  that  utilizes  die  tenninalciqiabilities  such  as  inserting  a  character  into  a  line  and 
scrolling. 

Screen  Perfonnance.  Tha  A!gi«inn«  regartting  ttw  tftrminiil  nprimirarinns  am  hawH  rm  thft 
degrees  of  diange  to  the  screen.  The  types  of  changes  diat  occur  are,  of  course,  dqiendent 
on  the  particular  data  structure.  It  is  beneficial  to  kxdt  at  how  die  data  repiesmitatimi  is 
organized.  For  die  screen,  the  data  structure  is  defined  in  terms  of  lines  and  characters.  To 
assess  adiat  has  dianged,  we  iwed  to  be  able  to  dxxxnpose  die  data  structure  in  various 
ways  so  we  can  determine  v^i^ier  some  pieoe  in  the  iqxiated  structure  is  the  same  as  some 
piece  in  die  original  structure.  To  accompliah  diis,  we  observe  each  data  structure  using  its 
accessor  functions.  For  die  scremi  example,  this  includes  fiinctkms  to  return  a  single  line 
or  some  subset  of  lines. 

How  is  change  introduced  into  the  screen?  Wb  start  widi  the  simplified  definidcm  for 
die  new  screen,  oonteiit(op(b)).  It  is  a  function  the  dddi^lay-editor  buffer  and  observed 
under  some  context,  oontenL  changes  can  we  observe?  Using  formal  manipulation, 
we  would  *ideally”  Uke  to  decompose  die  operadcm,  op,  into  smaller  pieces  diat  are  either 
accessor  functions  or  terminal  ct^abOity  funcdons.  The  accessor  functions  do  not  change 
die  portions  of  the  screoi  to  which  they  ate  qiplied.  The  terminal  cityability  functitms  do 
change  the  portions  of  die  screen  to  ^diich  they  are  ^lied,  but  do  so  efficimidy  by  using  the 
qwdalized  capabilities  of  the  terminaL  Whra  it  is  not  possible  to  decompose  the  operation 
in  such  a  manner,  die  operation  most  perform  juuts  of  die  computation  to  update  the  screen, 
or  update  the  oitire  screen. 

When  most  we  update  die  mitire  screen  and  when  can  we  make  more  local  changes? 
Whmi  manipolating  die  operations  for  die  display  editor  above,  we  focused  cm  two  local 
changes  and  one  global  change.  The  local  changes  consist  (rf**oveniding”  and  "offsetting** 
for  which  these  exists  tetmiiud  amiability  fiinctk»s  such  as  character  insertion  and  scrolling. 
Ovenidiiig  changes  die  screen  a  character  or  a  line  at  a  time.  Offsetting  shifts  die  characters 
or  lines  over  by  some  amount  When  insetting  a  vaa  newline  character,  the  characters  to 
die  ri^  of  the  poim  of  editing  on  the  cunem  line  ate  tiiifted  to  die  right  and  the  characta  is 
inserted  into  die  qiaceduu  is  opened  19.  The  global  change  dut  we  noted  was  updating  die 
origin.  In  diis  case,  updating  tte  oitire  screoi  is  warranted  because  diere  may  be  very  little 
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intbescteeadiatreiiiainsdiesaine.  We  made  no  distinction  for  when  die  origin  changes 
a  «n»n  amount  (less  dian  die  screen  hei^t)  and  a  great  amount  We  could  later  specialize 
die  former  case  to  scroll  when  i^licable. 


4.2  Multiple-Buffers  Single-Window  Display 

This  section  attends  the  example  by  adding  die  abili^  to  use  more  than  one  bufiCT  in  Older 
to  learn  bow  to  adi^  module  interfaces  by  creating  a  new  module  that  includes  an  old 
one,  and  dim  propagating  the  (^leratums  using  data-transformatum  techniques.  I^anew 
datatype  for  multqile  buffers  is  introduced  and  the  definitirxi  of  di^lay  editor  is  extended 
to  make  use  of  this  new  funcdonality.  Then  transformaticMis  for  integrating  the  muldple- 
Iniffers  data^pe  into  the  display  editor,  and  for  pn^gadng  die  old  ediunr  definition  into 
die  new  <xie  are  presented. 

42.1  Defining  a  Multiple-Buffer  Editor 

Basic  operatUms  for  a  multiple-buffer  editor  include  adding  a  new  buffer,  selecting  one  of 
die  buffers  for  display  on  die  screen,  and  deleting  a  buffer  from  the  buffer  list 

SgaataicMBUFsi^ 

typcnbuf 

maka-mbawr :  nbuf 
make-buffer :  str  x  wbut  — » nbuf 
eelect-buttar :  str  x  inbuf  — » nbuf 
kill-buffer :  nbuf  nbuf 


Let  us  look  to  the  previ^  definiticm  of  the  simple  di^lay-editor  for  guidance  in 
developing  a  new  rqnesentatitxt 

Upcded  a  DEdof  (buf  x  origin  x  screen) 

Since  we  are  dealing  with  more  than  <me  buffer,  we  would  like  to:  bui^e  together  the 
buffer  and  the  origin;  add  a  name  field  to  identify  die  buffer,  generalize  the  single  entry  to 
a  list  of  entries;  and  keep  die  selected  buffer ‘^cached”  separately  ffom  the  list 

The  r^nesentation  we  cone  up  widi  is  a  buffer  list  where  each  entry  cmisists  of  the 
Imffer  name,  the  actual  buffer,  and  the  origin  (that  pins  the  screen  to  the  buffer).  Thecunent 
buffer  (diqilayed  on  die  screen)  is  sqiarate  frmn  the  list 

type  nbuf  a  Mbuf  of  (str  x  buf  x  origin)*  x  str  x  buf  x  origin 

This  representation  was  chosm  to  simplify  the  presentatimt  Other  representations  are 
possibl^  For  example,  only  die  name  of  the  currmt  buffer  could  be  kept  separate,  and  then 
die  actual  buffer  and  origin  would  be  kxdced  iq>  in  die  buffer  list 

The  operations  are  earily  implmiented  uring  "generic”  association-list  opmatuxis.  We 
use  die  tmffer  name  as  die  key  to  insert  select  or  remove  items.  We  now  construct  a 
mult4>fe-bnffer  display-editoc. 
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Sipntac  DED-MBSW  s  sig 
Qiwded-nddsw 

make-ded-mb6w :  dad-ndasw 
ded-op :  (buf  -*■  but)  — ►  dad-mbsw  — » ded-inbsw 
make-buffer :  str  x  d«d-nbsw  —*■  ded-mbsw 
select-buffer :  str  x  ded-nbsw  -*  ded-sd9sw 
kilt-buffer ;  ded-sibsw  —*  ded-nbsw 


The  itptesentatiaa  for  die  multiple-buffer  di^lay-editor  combii^  die  buffer  list  with  the 
soemL 

^fpc  ded-iift>sw  ■  Ded-Mbsw  of  mbuf  x  screen 

The  implementations  of  die  operatuxis  for  the  multiple-buffer  display-editor  are  derived 
finran  Mbuf  and  OEd.  The  relationship  between  these  modules  is  ei^ressed  in  tenns  of 
a  translation  functicm  and  the  familiar  integration  techniques  ate  applied  to  obtain  new 
implmnentatioos  of  operations  based  on  the  imported  modules. 

4J2J,  integrating  the  Buffer-List  Operations 

The  bufifer-Ust  operaticHis  defined  in  Mbuf  induce  corresponding  operatkms  in  the  multiple- 
bufferdisplay-emtordiataredefinedasdatattansformprocediires.  The  relationship  between 
the  Mbuf  module  and  the  Oed-Mbsw  module  that  includes  it  is  mqitessed  as: 

span :  inbuf  — » ded-mbsw 

8pan(Mbuf(b*,s,b,0))  Ded-MbswOtbufCd*,  n,  b,  o),  s) 

wrberi  s  •  dl^to-scre^o',  b) 

The  operaticms  defined  in  Mbuf  ate  thmi  reimplmnented  in  Ded-Mbsw.  For  example, 
the  new  definititxi  fra*  select-buffer  is: 

select-buffer'fa.  soarkMbuffy .  s.  ft.  offl  span(8elect-buffer(s,  Mbuf0*,  n,  b,  o))) 

After  a  number  d  transformation  steps,  we  obtain: 

select-buffer'(n,Oed-Mbsw(M,^))  Ded-Mbsw(M',  ^ 

wherc^asMbuf(6*,n,fr,o)sselect-buffer(n,  bl), 
/  « cii8p-to-8creen(0,  b) 

In  this  simple  case  module  inclusicm,  the  operatitms  in  Ded-Mbsw  call  the  operations 
in  Mbuf  and  then  update  the  scteoi  accordingly.  We  could  continue  to  specialize  die 
operaticms  so  that  die  sctemi  is  incrementally  updated  as  was  done  in  die  previous  example. 

4.23  Integrating  the  Buffer  Operations 

The  buffer  operations  from  DEd  (eg.,  deleta,  insert,  riKive-right)  induce  conespcmding  tolera¬ 
tions  in  the  multiple-buffer  display-editor  that  can  be  d^ned  as  data  transform  procedures. 
Ihe  relationship  betwemi  die  DEd  module  and  the  Ded-Mbsw  module  that  includes  it  is 
eiqxessedas: 
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unspan :  die<l-iift»aw  -*  ded 

urapanped-MbswCHbu£(^*,fi,6,o),j))  <=  DEd(fr,  o,  s) 

The  fundamental  <q)eiad<xis  <m  the  buffer  must  be  reimplemented  in  Ded-Mbsw.  They 
are  ejqnessed  in  terms  of  the  transladmi  function  and  the  definiticHis  defined  for  the  simple 
display-editoi;  DEd.  Intuitively,  the  new  implranrataticms  simply  operates  on  the  “cached” 
portion  of  the  buffer  list  Theimwdefinitimiforded-opis: 

un8pan(de<^op(c,Ded-Mb8w^uf(t>*.it,&,o),j)))  <= 

DEd.ded-op(c,  unspanO)ed-Mb8w<Mbu£(fr*,  n,  b,  o),  s))) 

Rrst  we  unfold  unspan, 

un8pan(ded-op(c,  Ded-Mbaw(Mbuf(y  j)))  ^ 

DBd.de(^op(c,  DEd(6,  o,  r)) 

and  then  unfold  declop. 

un8pan(ded-op(c,Ded-Mbsw^u£(6*,n,^o),5)))  <= 

kto'apoHcyCo,  60iB 

kty  « cfl^to-saeenCo',  I/)  in 
DEd(y,  s',  oO 

Recognising  the  body  of  unspan,  we  fold  it, 

un8pan(ded-op(c,Ded-Mb8wQCbu£(d*,ii,fr,o),j)))  <= 

Ict6'«c(fr)in 

lcto'>poliqr(o,  ^ia 

let  y  «  d'sp-toocreenCo',  V)  in 

unspanODed-Mb8w^u£(fr*,  n,  V,  </),  f)) 

and  then  take  a  solution. 

dSdop(c,Ded-Mb8if(Hbu£(6*,A,6,o),r))  <= 
kt6'-c(fr)iB 

lety-poHcyCo,  60 

let  y  s  disp-to-saeency,  V)  fat 

Ded-Mb8w(Mbu£(fr*,  n,  tf,  of),  f) 

The  new  implmnmitaticm  for  ded-op  simply  (iterates  on  the  selected  buffer  in  die  buffer 
list  Rather  than  choosing  die  general  definidcm  for  ded-op,  we  could  have  chosen  instead 
the  specialised  versioos  of  the  operadcms  that  optimize  the  screen  iQxiaies. 

We  can  dunk  of  this  devekqimmit  process  as  a  means  to  ad^  interfaces.  We  wanted 
to  chan^  die  interface  of  the  simple  di^lay-editor  DEd  to  include  operations  fcv  dealing 
widi  multiple  buffers.  Wb  ad^  die  int^ace  by  dining  a  new  compcment  Ded-Mbsw 
and  express  die  tdatioosh^  between  it  and  DEd  with  a  translaticHi  fiincticm.  Then  we 
reimplement  die  operations  in  DEd  into  Ded-Mbsw  using  the  data  transformation  technique. 
The  technique  provides  a  systmnatic  way  to  propagate  change. 
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43  Multiple-Buffers  Multiple-Windows  Display 

This  sectu»  extrads  the  example  by  adding  the  ability  to  di^lay  more  than  (me  buffer 
(m  die  screen  at  (me  time  to  dem(mstrate  how  to  adapt  module  interfaces  by  eiqiosing 
underlying  represmtations.  This  involves  introdurung  the  crmcept  of  a  window  (m  the 
screen.  Rather  than  introducing  a  new  datatype,  as  was  done  in  previous  sectitms,  the 
expose  transfonnatitm  is  used  to  reveal  the  window  object  from  the  previous  definition  for 
diescremi.  Once  the  buffer  and  screen  are  decoupled,  (qieratkms  for  multiple  windows  are 
introduced  Then  the  display  editor  is  extended  to  include  this  new  functionality  and  the 
previous  versums  propagated  as  was  dtme  in  the  previous  sectioiL 

43.1  Defining  the  Multiple-Window  Editor 

Basic  (qieratkms  for  a  multiple-window  editor  include  deleting  a  window  from  the  screen, 
enlarging  a  window  (by  a  line),  moving  the  focus  d  attention  (marked  by  the  cursor)  to 
another  window,  shrinking  a  window  (by  a  line),  and  splitting  a  window  into  two  smaller 
halves. 

S^aatvc  MHIN  s  sig 
Openwln 

make-mbimv :  mrin 
deleta-wirKioiM :  xnrin  —*  mrin 
erdargo-window :  nwin  -*  mrin 
other*win(iow :  mrin  -*  mrin 
shrink-wirKkiw :  nwin  — *  nwin 
split-window :  nwin  — » nwin 

end 

We  build  (mocarinevioos  work  to  construct  a  new  definitirm.  But  where  does  the  notion 
of  window  come  from?  Is  it  a  new  ccmcept  that  most  be  introduced  into  the  system,  or  is 
it  somewhere  hidden  in  the  previous  definititm  waiting  to  be  uncovered?  In  die  previous 
definition,  there  is  an  (iperatkm  for  nupping  a  display  into  a  screen.  We  would  like  to 
expose  more  details  of  tto  (peratitm  by  showing  how  Ae  display  could  instead  be  mapped 
into  a  window,  which  is  then  mipped  into  the  screen. 

433  E3q;)osing  the  Window 

The  goal  of  diis  process  is  to  introduce  a  new  datatype  for  windows.  We  start  off  with 
a  frinctum  for  mapping  a  display  plane  into  a  screen.  We  add  the  screen  surface  as 
an  extra  parameter  rather  than  accessing  it  s;  a  state  variable.  The  idea  is  to  reveal 
the  underiying  data  representatitm  of  the  data  abstraction,  eipressing  it  in  tnms  of  a 
tuple  of  odier  reptesentatitms.  (The  details  of  the  expose  transformation  are  explained  in 
S^oo  6.2  J.) 

This  transfonnatirm  is  possible  if  we  are  able  to  write  a  funetkm  that  spans  these 
representations.  The  Unspan  fimetum  maps  a  tiple  rqnesenting  a  window  and  a  new  land 
(ff  scremi  into  the  original  data  representatitm  for  tile  scremi. 


43.  Multiple-Bikers  Multiple-Windofws  Display 


71 


tixsp-\o-9CxaaTiprig,b,ss)  ^ 

Uip^  oontent(6)  o  projectCorig) 
and  c  sat  current(6) «  project(0K<^) 
and  ^Hices  =  (Ai  j :  N .  ‘9’)  in 
Screen(c,  (iqxuxs  ® p)\ss) 

Using  the  expose  transfonnation,  we  seek  to  get  all  instances  of  the  data  abstraction  to 
be  of  the  form  data  abs  o  Unspan. 

Unspan  :  (cursor  x  appearance)  x  (cursor  x  appearance)  — *•  (cursor  x  appearance) 

antiproj :  origin  —*■  cursor  -+  planepos 

antiproj(r,cXi,/)  <=  {i-i’J-c) 

titsp-\sysaa&n(pHg,b,ss)  •«= 
let  />  =  oontent(h)  o  project(on;) 
and  c  sat  current(b)  -  project(oXc) 
and  spaces  -  (XiJ :  N .  'sp') 
and  on/ -  (0,0) 
and/  s  spaces  0/> 
and  p"  s  p'  o  anti^Kon/) 
and  d  s  project(cKort/)  in 
Screen(Unspan((c,  p‘\ss),  (d,  p"\rs))) 

Replace  dnta  abs  o  Unspan  with  unspan  0  {window,  Screen').  This  moves  the  boundary  of 
the  type  inward,  revealing  two  new  abstractions  in  the  process. 

disp-tO'Screen(ori«,6,ss)  ■«= 
let  p  »  contenVb)  o  project(arig) 
and  c  sat  current(h) »  project(oKc) 
and  spaces  =  (MJ :  N .  'sp'} 
and  on/ =  (0,0) 
andp's  unices  0p 
and  p^'  ^  pf  o  anti^Kon/) 
and  d  -  project(cXori/)  in 
unspan(Window(c,  p^\ss),  ScreenV.  /'\»)) 

Excise  unspan  and  then  split  disp-to-screen  into  two  separate  functions. 

disp-tO'Saeen(onj,h,«)  •*=  window-to-screen(disp-to-window(6,ong,M),  (0,0),  ss) 

dtep-to^'ndow(6,or(g,w^)  ■«= 
let  p  »  oontent(h)  o  project(ori«) 
and  c  sat  curre^A) »  prDject(oXc) 
and  ^poces  «  (Al,y :  .V .  *q)’)  in 
Window(c,  (jpocer  0p\nv)) 

window-to-8aeen(or<s,w,ar)  <«= 
let  p  «  w  appearance  o  antipraj(on;) 
and  c  *  praject(H'.cursor)(on;)  in 
Screen'(r,  p\ar) 
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433  Building  the  Display  Editor 

Now  that  the  notion  of  windows  has  been  revealed,  we  define  the  multiple-buffer  multiple- 
window  display-editor.  The  representation  consists  of  the  buffer  inftnmadon  from  the 
previous  section  cm  multiple-buffers  single-window  displays,  plus  a  window  list  where  each 
entry  consists  of  the  window  name,  the  actual  window,  tte  name  of  the  buffer  associated 
with  the  window  and  an  origin  that  pins  the  window  to  the  screen.  The  selected  window  is 
separate  from  the  window  list 


type  mwin  *  Mwin  <rf  (str  x  window  x  str  x  (n  x  n))*  x  (str  x  window  x  st  r  x  (n  x  n)) 


This  representation  was  chosen  to  simplify  the  presentation.  As  with  multiple  buffers,  other 
representations  are  possible.  For  example,  only  the  name  of  the  current  window  could  be 
kept  separate,  and  dien  the  actual  window  and  origin  would  have  to  be  looked  up  in  the 
window  list 

We  now  construct  a  multiple-buffer  multiple-window  display-editor. 


Signature  DED-MBMMT = sig 
type  ded-oibmw 

make-ded-mbmw :  ded-mbmw 
ded*op :  (buf  — ♦  buf )  — >  ded-mbmw  — ♦  ded-mbmw 
make-buffer :  str  x  ded-mbmw  — ►  ded-mbmw 
select-buffer :  str  x  ded-mbmw  — *  ded-ndmaw 
kill-buffer :  ded-mkmtw  — » ded-mbmw 

delete-wiixlow :  ded-mbmw  —*  ded-mbmw 
enlarge-window :  ded-mbmw  — » ded-mbmw 
other-window :  ded-inbmw  —*  ded-mbmw 
Shrirtk-window :  ded-mbmw  —*■  ded-mbmw 
split-window :  ded-adanw  — » ded-mbmw 

end 

The  representation  for  the  display  editor  combines  tl»  buffer  list  the  window  list  and  a 
new  notion  of  screen. 


type  ded-mbmw  =  Ded-Mbmw  of  mbuf  x  mwin  x  screen' 


We  can  profligate  the  opoations  as  was  dime  in  the  previous  section.  The  implemen- 
taticms  oi  die  operations  f<x^  the  display  editcr  are  derived  firom  Mwin  and  the  preceding 
multiple-buffer  display-editoc  The  relatitxiship  between  tiaesc  modules  and  tte  diqilay 
editor  can  be  expressed  in  terms  of  atranslati(»  function  and  the  familiar  integraticMi  tech¬ 
niques  can  be  applied  to  obtain  new  implmnentaticms  of  qieratimis  based  on  die  imported 
modutes. 


4.4.  Summary 
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4  J.4  Integrating  the  Window-List  Operations 

The  window-list  operations  defined  in  Mwin  induce  cortesponding  q)erations  in  the  display 
editor  that  are  defined  as  data  transfocm  procedures.  The  relationship  between  the  Mwin 
module  and  the  Ded-Mbmw  module  that  includes  it  is  e]q>ressed  as: 

span :  mwin  ded-naxnw 
spanOtwin(H'*,wfi,w,6ii,w0))  <«= 

let  5  s  window-to-saeen(wo,  w)  o  mapwinOwindow-to-screen,  w*)  in 
Oed-Mbmw(Hbuf(6*,  n,  b,  o),  Mwin(N^*,  wn,  w,  bn,  wo),  s) 

The  mapwin  operation  recurses  through  the  window  list»  aj^lying  window-to-screen  to 
each  entry  in  order  to  update  the  screen.  The  ppoatimis  defined  in  Mwin  can  then  be 
teimplemented  in  Ded-Mtow.  They  could  simply  call  the  old  operation  and  then  update  the 
screen  appropriately. 

4  J.5  Integrating  the  Buffer  Operations 

The  buffer  operations  defined  in  the  preceding  mulfiple-buffer  display-editor  induce  corre¬ 
sponding  operatitms  in  the  display  editor  that  can  be  defined  as  data  tiansfonn  procedures. 
The  relationship  between  the  Ded-Mbsw  module  and  the  Ded-MDUmw  module  that  includes 
it  is  expressed  as: 

unspan  :  ded-mbmw  — » ded-mbsw 

unspan^ed-MbmwCMbuf  (b*  ,n,b,o),  Mwin(w*  ,wn,w,bn,  wo),  s))  <= 

Vitw'^{w  I  disp-to-winclow(o,b) }, 
y  =  winclow-to-screen((0,0>,  W)  la 
Ded-Mbsw(Mbuf(6*,  { n  |  bn},b,  o),  s) 

The  operations  on  the  buffer  must  be  reimplemented  in  Ded-Mbmw.  As  before,  the  new 
implementatitm  (^)erates  <m  the  “cached”  portion  of  the  buffer  list  In  addition,  it  updates 
the  appropriate  window,  and  then  the  entire  screen. 


4.4  Summary 

The  module  structure  of  the  evolving  display-editor  is  shown  in  Hgure  A2.  Module 
inclusum  is  renressnted  by  solid  lines  between  two  modules.  The  module  above  is  included 
in  the  module  below.  Translation  functions  are  represmited  by  arrows.  Derivations  are 
represented  by  dashed  lines.  They  are  numbered  and  refer  to  the  items  in  the  enumerated 
li^  below.  Different  kinds  of  adi^tation  include: 

1.  When  a  screeniK^  added,  the  buffer  did  not  have  the  necessary 

q)erati(ms  to  interface  with  the  display;  two  additional  pperaticmswme  needed.  They 
were  added  by  creating  a  new  cmnptment  for  them,  Buf^u^,  and  tl»n  integrating  the 
comptment  into  the  original  system,  Buf  using  the  techniques  for  adiqjtation 
discussed  in  Sectkm  32. 
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Figure  42:  Module  Hierarchy 


4.4.  Summary 
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2.  Incorporating  substructure.  The  buffer  and  screen  communicate  dvough  a  narrow 
uni-directional  channeL  This  is  accomplished  by  the  cfisp-to-screen  function  that 
converts  an  entire  buffa  into  a  screen,  it  is  possible  to  incorporate  the  modules  for 
the  buffer  and  the  screen  into  tibe  display-editor  module,  ded,  in  order  to  widen  the 
channel  of  communicatitML  This  allows  local  changes  in  the  buffer  to  be  reflected  in 
the  screen  using  a  form  of  incremental  i^xlate.  The  channel  of  (xmununicaticm  could 
also  become  bi-diiecti(Mud  so  that  changes  in  the  screen  are  reflected  in  the  buffini 

3.  Extending  Modules.  A  series  of  display  editors  were  built  that  progressed  firmn  having 
a  single  buffer  and  a  single  screen,  ded,  to  multiple  buffers  and  a  single  window, 
ded-mbsw,  to  one  with  multiple  buffers  and  multiple  windows  displayed  in  a  screen, 
ded-mlxAw.  As  we  progressed  through  the  series  of  display  editors,  interface  fm* 
the  previous  editor  was  adi^ted  by  creating  a  new  module  that  includes  the  old  one, 
and  then  the  operations  were  propagated  using  data  transformation  techniques. 

4.  Ejqposing  Information.  Sometime  (ht  changes  to  the  interface  are  hidden  within 
the  existing  system.  Instead  of  adding  something  new,  a  more  synthetic  tqjproach 
is  taken  where  the  desired  intoface  is  exposed  from  existing  information.  When 
constructing  ded-mbmw  the  concept  of  a  window  emerged  between  «he  abstractions 
for  the  display  and  the  screen. 
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Chapter  5 


Interpreting  the  Results  of  the  Editor 
Derivation 


The  module  interface  transfonnadmi  system  presents  an  overall  methodology  to  guitte  the 
software  development  process,  but  there  are  still  many  choices  to  be  made  by  the  software 
dev  eloper.  A  particular  line  of  development  was  chosen  in  tte  editor  example,  but  at  certain 
points,  other  choices  available  to  the  software  developer  were  indicated.  In  this  chapter,  the 
range  of  choices  are  classified  at  the  design  (Sectitm  5.1)  and  implmnentation  (Sectitm  5.2) 
levels  of  integration.  These  choices  are  evaluated  in  terms  of  die  costs  they  incur  during 
the  transfonnatum  process,  the  range  of  choices  available  at  the  lower  levels,  and  the 
performance  of  the  resulting  implmnaitatitm.  The  software  designer  will  have  to  weigh 
these  factors  and  make  tradeoffs  between  them.  Section  5.3  discusses  the  implications  of 
this  approach  to  scaling. 


5.1  Integration  Design  Alternatives 

The  chmces  available  to  die  software  designer  for  integrating  the  collecticm  of  com- 
ptxients  into  an  aggregate  ate  depradent  on  die  prcqieTties  of  die  comptments  and  the 
relationships  amcmg  them.  Recall  that  a  canponent  consists  of  a  data  structure  and  a 
coUectitHi  of  operations;  they  are  related  by  consisteiicy  relations  implemented  as  compat¬ 
ibility  maps  or  translaticm  functitms.  Oxnptnmits  are  used  for  ctmstructing  datatypes  or 
(dijects.  Now  ctxisider  die  integration  process.  The  inputs  to  die  process  ate  the  coll^mi 
qS  components  and  translation  functions  with  certain  properties,  and  the  choices  made  by 
the  software  developer.  InHgure5.1  we  chart  the  integratitm  choices  made  by  die  software 
developer  in  terms  oi  the  effects  diey  have  on  the  outcome,  (i.e.,  die  data  aggregate).  TWo 
useful  measures  are  the  levd  of  abstraction  of  die  data  rqnesoitation  for  die  data  aggregate 
and  the  time  evaluation  of  the  translation  functions  and  component  c^ioraticms  in  die  data 
aggregate 

Chdces  for  die  data  rqnesentation  sppta  on  die  **abstracticm*’  axis.  Starting  at  the 
top  and  moving  downwards,  first  a  single  component  rqaeaentatimi  is  diosen,  dien  the 
unkn  of  all  representations,  and  finally  the  {uoduct  of  the  rqiresentations.  Below  duu 
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(but  not  shown)  could  be  a  more  generalized  lepresentadtHL  Recall  diat  each  ccnnponent 
(qieratum  induces  an  aggregate  operation.  Onech(nce,thmi,istou8e(n)eoftkec(xnp(ment 
rqnesentatitHis  as  die  aggregate  representation.  The  aggregate  operations  induced  from 
the  compmient  operations  must  be  defined  to  operate  mi  t^  chosen  representation.  A 
secmid  choice  is  to  use  all  compmient  representations  in  the  aggregate  r^nesentation. 
The  aggregate  representatimi  could  be  die  disjoint  union  or  the  product  of  the  component 
represmitatimis.  The  induced  operatimis  on  tte  aggregate  must  ensure  the  consisteiury  of 
all  of  the  cmnpmient  representatuHis.  If  the  representatimis  of  some  of  the  components  are 
identical  tten  die  data  can  be  shared.  Operations  access  die  shared  data  representatum. 

Gmipmients  and  aggregates  tqipear  <m  the  “evaluation  time”  axis.  Starting  at  the  right 
and  moving  to  the  left,  die  cmnpmients  at  first  becmne  specialized  by  incorporating  the 
translation  fiinctimis,  and  then  diemselves  becmne  incorporated  into  die  aggregate.  Since 
each  compoirent  t^ieratimi  induces  an  aggregate  operation;  for  any  operation  tinned  on 
a  compmimit,  a  new  aggregate  operatimi  can  be  defined  that  is  derived  or  translated.  A 
new  operatitm  may  be  derived  that  operates  direcdy  on  the  new  representation.  This 
is  accomplished  by  defining  the  new  operaticm  in  terms  of  die  old  as  a  data  transform 
procedure  and  applying  transformations  to  obtain  an  executable  implementation.  As  an 
alternative,  die  new  tqieratimi  may  be  translated  by  defining  it  in  terms  of  the  old  operation 
and  translatimi  functions.  For  example,  die  new  t^ieratimi  could  use  translation  functions 
to  first  translate  the  data,  apply  the  compcment  t^ieratimi,  and  then  translate  back. 

The  choices  made  in  integrating  die  comptments  affect  how  the  translatimi  functions 
are  used  in  the  aggregate:  (1)  The  translatimi  functions  are  maintained  and  die  aggregate 
operations  dynamically  evaluated.  In  diis  case  d»  aggregate  qperations  are  translated.  (2) 
'nanslation  functums  are  partially  compiled  inu>  die  new  implonentations  cS.  the  (derations, 
but  there  is  still  some  dynamic  tqxlate.  (3)  The  translation  functimis  are  compiled  into  the 
new  implementatimis  df  the  tqietatimis.  In  this  case  die  aggregate  qierations  are  derived. 

For  the  sake  of  cmicreteness,  imagine  diree  compmmits,  each  defining  a  sqiarate 
qieraticni  cm  differrot  data  representatimis.  The  operatimis  and  data  rqiresentations  are 
shaded  to  distinguish  them.  Qmsider  the  case  where  the  operaticm  of  the  middle  cmnponent 
induces  an  (iteration  on  the  aggregate.  The  numbers  in  Hgure  S.l  corre^nd  to  die  items 
discussed  below  where  we  pinpoint  some  of  dte  choices: 

1.  /ncremenla/ merging.  The  translation  fiinctions  and  die  cmnpcmentoperatirxi  are  ma¬ 
nipulated  to  derive  an  operaticm  on  the  aggregate  that  exploits  dte  inteidepmidencies 
among  the  comptment  representatimis.  This  was  dte  choice  for  die  buffer  prototype 
semi  in  Figure  3JS. 

og,^j(8pan(c2))  8pan(op,(ci)) 

un8pan(gg(ag3(ci,c2,c3)))  ^  op,x2(un8pan(agg(ci,  C2,  cs))) 

The  aggregate  operation  is  defined  as  a  data  transfionn  procedure  wbm  translatkm 
fimctiominse  compatibility  nuqis  and  mqiloit  the  inierdqtendmictes  among  the  com¬ 
ponent  representations.  Refer  to  Hgure  S.l  at  die  module  labeled  (1).  Startatdieteft 
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of  the  module  and  follow  die  arrows  to  observe  how  the  data  rqnesentadtHi  is  used. 
In  dds  case  the  aggregate  (qiecatums  act  direcdy  on  the  aggregate  data  rqnesmitatioii. 
The  reptesentadtxi  is  first  accessed  by  an  opoadon  and  then  is  updated  with  tte  new 
result 

2.  Product  of  the  (^rations  on  the  union  of  the  data  representations.  Alternative 
implementaticms  of  the  ccHupooent  operation  are  derived  for  the  other  compcments. 
Then,  depending  cm  die  current  ^pe  of  tte  aggregate,  the  appropriate  opoation  oa 
that  type  is  selected.  This  alternative  was  not  actually  implmented  in  the  buffer 
example,  but  could  have  been  by  defining  the  aggregate  operation,  op,  in  terms  of 
die  current  type  (tf  the  ctxnpcxient 

op(agg)  «=  casetypeof(agg)is 

ciTtiMUOPiCagg) 

C2J'thaiop2(agg) 

csTtbenopjCagg) 

Refer  to  Hgure  S.l  at  the  module  labeled  (2).  Again  start  at  the  left  to  follow  how 
the  data  representation  is  used.  The  data  is  accessed  by  die  impropriate  component 
dud  matdies  its  cuirrat  type.  The  component  performs  the  appropriate  operation  to 
update  the  representation  with  the  new  result. 

3.  Product  of  die  (^rations  on  the  product  of  the  data  representations.  As  with  the 
product  of  the  operations  on  die  union  of  the  rqnesmtations,  alternative  implemen- 
tatums  of  the  cmnponenttmeratimi  are  derived  for  die  other  ccMnptxients.  But,  since 
the  data  representaticm  is  now  the  product,  all  of  diese  alternatives  must  be  selected 
to  update  the  corresponding  part  of  the  aggregate.  This  choice  was  discussed  as  a 
possibility  for  the  buffer  prototype,  seen  in  Hgure  3.3. 

op(Agg(ci,C2,C3))  «=  Agg(c',,  cj,  c^) 

when  cj  «  op,(ci) 
and  c4  «  0P2(C2) 
aodc^  »  0t^(C3) 

Refer  to  Hgure  5.1  at  the  module  labeled  (3).  The  data  a^regate  rqnesentatitxi, 
which  is  the  product  of  the  component  representations,  is  projected,  each  comptment 
accessing  the  ptoce  that  corresponds  to  its  own  data  rqnesentatum.  Thisisusedby 
each  cranponent  operation  and  die  results  are  combined  to  yield  a  new  aggregate 
result  In  dus  oample,  die  operation  of  the  middle  component  is  given.  The 
alternative  imphanentations  of  die  component  operation  are  d^ned  as  data  transform 
procedures  for  die  top  and  bottexn  oomponmits. 

4.  Translating  on  a  comptment  representation.  Chie  component  is  chosen  for  die  data 
repreaentatioo  of  the  aggregate.  For  die  sake  d  concreteness,  consider  using  the 
first  component  data  rqiresentation.  The  aggr^ate  operation  is  implemmited  using 
die  oompatUdlity  nugM  to  translate  to  die  component  aiiere  die  operation  is  defined, 
performing  die  operation,  and  then  translating  back. 
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op(agg)  <=  mapi^jCopiCmapi^aCagg))) 

5.  Translating  on  the  union  of  the  data  representations.  Depending  on  the  cunent  data 
representation  of  the  aggregate,  it  must  be  translated  to  the  component  where  the 
operatitHi  is  defined  before  the  (q)eraticm  is  performed.  There  is  no  need  to  translate 
back,  because  the  aggregate  is  the  union  of  all  cmnponents.  Hiis  alternative  was 
not  actually  implemented  in  the  buffer  example,  but  could  have  been  by  defining  the 
aggregate  operation,  op,  in  terms  of  the  current  type  of  the  component 

Op(agg)  <=  case  typeo^agg)  is 

Cl  Tthen  op2(n>ap,^2(agg)) 

C2T  then  opjCagg) 

C3  J  ttcn  0P2(map3_2(agg)) 

6.  Translating  on  the  product  of  the  data  representations.  This  choice  far  implementing 
the  aggregate  is  inspired  directly  by  Ae  aggregate  definitimi  seen  in  Hgure  32. 
'^th  compatibili^  nu^  implementing  the  consistency  relations,  then  the  aggregate 
qperatirxi  is  defined  by  extracting  crxnprment  representation  frmn  the  product 
perfonning  the  (^teraticxt  and  then  using  the  compatibility  maps  to  update  all  portions 
of  the  product 

Op(agg)  «=  proji-‘(op2(proi2(agg))) 

The  projection  extracts  die  appropriate  comprment  the  inverse  of  the  projection  is 
defined  in  terms  of  the  compadbility  m^  to  produce  the  aggregate. 

The  choice  for  is  at  (1)  in  Hgure  S.l  but  alternatives  (3)  and  (6)  were  also 

ctmsideted  in  the  discu^on.  Merging  the  pages  and  xegicms  cmnponents  also  ate  at  (1). 
Translating  die  pages,  s-exptessions,  and  di^lay  comptments  ate  at  a  positicm  higher  up  at 
the  tt^left  in  tte  diagram. 

Tte  integration  altemad  ves  of  merging  or  translating  with  the  components  of  the  original 
system  or  the  implonentatitxi  can  also  be  seen  in  this  diagram.  Translating  is  near  the  top 
and  to  the  right,  where  txily  (me  of  the  component  representations  is  chosen.  This  requites 
the  implemoitations  for  the  operaticms  on  die  other  compcments  be  translated.  Moving 
downwards  and  to  the  left  shows  die  alternatives  for  merging.  At  the  botumi  left,  tince  all 
of  the  ccxnptment  data  representations  qipear  in  the  aggregate,  and  the  translation  functions 
have  been  inccrpcsaied  into  die  operation  definiti(ms,  diete  is  no  other  alternative  than  to 
ensure  that  each  (operation  iqxlatBS  the  aggregate.  Tlieteareac(mtinuoussetof<dioices,the 
alternatives  are  not  restricted  to  die  discrete  set  diown  in  the  figure,  which  highlight  some 
of  the  interesting  choices. 

5.2  Integration  Implementation  Alternatives 

It  is  desirable  diat  the  software  developer  understand  die  costs  associated  with  die  various 
alietnidives.  This  section  first  discusses  die  cost  measures  available  for  making  this  analysis 
and  dial  looks  at  die  choioes  and  costs  made  in  die  di^lay-editor  doivation. 
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5.2.1  Cost  Measures 

What  criteria  about  the  cost  of  integration  is  available  to  make  the  various  decisions  to 
implmnott  the  aggregate?  One  way  to  measure  the  cost  of  integrating  a  collection  of 
components  is  to  count  the  number  of  data  transform  procedures  that  must  be  defined 
(which  is  proporticmal  to  the  number  of  data  transformation  stq)s  q>plied).  The  number  of 
definititms  that  must  be  added  for  each  component  widi  n  operations  is: 

n  (q)erations  x  m  merges/operadon 

Gmsidering  the  collection  of  components  and  oxnpatibility  mq>s  that  connect  them  as  a 
graph,  **mages**  is  the  sum  of  the  length  oi  the  paths  between  the  component  being  merged 
and  doe  other  ctHnptments.  Duplicate  paths  are  factored  out  For  example,  referring  to 
Figure  3.7,  this  is  2  for  Buf  2  since  it  must  reach  Bufj  through  Buf  1. 

The  cost  of  adding  a  component  to  an  existing  system  of  integrated  components  is 
also  measured  in  the  the  number  of  data  transform  procedures  that  are  defined.  Given  a 
core  system  with  m  comptmmits  and  /  operations  and  a  new  component  with  n  iterations, 
dien  merging  with  the  original  comptments  may  add  up  to  m  (data  transform  procedure) 
definitions  for  each  imw  iteratm.  The  number  of  ctmiptments,  m,  serves  as  an  upper 
bound  on  the  number  of  metges  required.  In  addititni,  diere  are  /  definitions  to  update  the 
existing  ^stem,  giving  a  total  of  n  xm-»'/definiti(»is.  Irimslating into  the  original  system 
adds  up  to  m  definitions  for  each  new  operation,  the  original  systmn  remains  unchanged. 

The  number  of  definitions  is  directly  proportional  to  dte  numba  to  transformation  steps 
necessary  to  implement  a  fiincticmal  prototype.  Based  <m  experience,  diere  ate  on  the  order 
of  10  derivation  stqis  necessary  to  transform  a  data  transform  procedure  into  a  functional 
definiticm.  Approximately  10  percoit  of  these  steps  are  insight  stqis.  (See  Appendices  C 
and  D  for  examples.)  More  eiqierience  clearly  is  needed  to  infer  the  number  of  steps  for 
general  problems.  Itisuseful  tomakethisdistinctitm  between  die  insight(or*‘eureka”)  steps 
and  the  others  because  the  former  require  manual  assistance  firran  the  software  developer 
whereas  most  of  the  stqis  of  die  latter  can  be  automated.  It  is  difficult  to  quantify  the  effort 
required  by  the  software  devdcqier  in  absolute  terms.  Thus  the  scenarios  below  discuss 
the  relative  costs.  Althcm^  there  may  be  mote  steps  in  some  cases,  the  dfort  required  by 
the  software  developer  may  be  less  than  the  other  alternatives  with  fewo’  s^is  because  the 
problmn  is  brokmi  into  smaller  concqmial  pieces  that  are  easier  to  reason  about  Often,  the 
amount  of  work  by  die  scdtwaie  developer  is  greater  initially  (especially  in  a  new  problem 
domain),  Imt  as  the  derivation  progresses,  more  information  is  gadmed  that  can  be  reused; 
thus  die  cost  is  amortised  over  the  duration  of  the  derivatitm.  The  cost  of  integrating  the 
component  depends  on  the  integration  alternative. 

Mergfa^  with  the  OrigiiialSystaii.  In  metg^gwidi  die  origiiud  system,  new  implemen¬ 
tations  aredexivedforoperatumsaf  die  new  ccxnpcmmit  (requiringn  xmdefinitiems).  New 
inqdemeatations  must  also  be  derived  for  die /operations  of  the  existing  compcxmits.  The 
existii^  derivations  for  die  dd  implmnmitations  of  die  tolerations  can  be  reused  direedy. 
The  derivatoi  riructnre  for  the  new  operations  may  be  similar  to  diat  of  the  old  operatitms 
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so  that  insists  may  be  reused  as  welL  The  specializadcm  step  requires  transfonning  the 
sum  of  all  die  operations,  /  +  n,  and  may  reuse  informadon  about  specializing  the  original 
system. 

There  are  more  steps  involved  in  merging  the  new  compcment  with  the  original  system 
than  in  the  other  altemadves,  but  they  may  be  simpler,  requiring  less  user  insight,  since 
more  information  is  available.  Since  there  is  more  information,  more  optimization  choices 
are  available.  The  representati<m  of  the  specialized  aggregate  may  be  different  from  the 
original  ^stem.  For  example,  in  the  buffo'  implementation,  we  kept  Buf  i  and  deleted 
Buf  2,  but  we  may  wish  to  reverse  the  decision  if  the  new  component  is  used  frequently  and 
is  mote  efficient  in  Buf  2. 


Tlranslating  into  the  Original  System.  In  translating  the  new  component  into  the  original 
system,  new  imptonentations  are  derived  for  operations  of  the  new  component  (requiring 
n  X  m  (tefinitions).  Since  the  original  system  does  not  change,  new  implementations  do 
not  have  to  be  derived  for  the  operations  of  tte  existing  components.  The  specialization 
step  requires  transforming  the  sum  of  die  operatirms,  but  since  the  original  system  does  not 
change,  the  information  about  specializing  dw  original  system  can  be  reused  direcdy.  The 
cost,  n,  is  incurred  in  specializing  the  operaticms  of  the  new  component 


Merging  with  the  Inqilementaticm.  When  merging  die  new  compcment  with  the  imple- 
mentatum  instead  of  the  origiiud  system,  then  the  number  of  components,  m,  is  no  longer 
a  useful  measure  for  the  upper  boimd  of  merges  required  because  many  of  the  components 
may  be  specialized  or  eliminated  in  the  aggregate  implmnentation.  Therefore,  f  (m)  is 
used  instead  to  indicatB  the  affect  of  the  spedatizaticm  step.  In  the  buffer  implementation 
example,/  reducedmabootSOpercentbecausetheprototypeaggregateconsistedofBufi, 
Buf  2,  and  Buf  3  and  the  implonentatitm  step  deletes  Buf  2  and  simplifies  Buf  3  so  that  there 
is  less  work  in  merging  widi  the  aggregate. 

Tlwre  are  fewer  steps  involved  in  merging  with  the  implementation  than  in  the  alterna¬ 
tives  discussed  above,  howevo:,  they  may  be  more  comply  since  the  ‘‘natural”  rqiresaita- 
tioQ  of  the  component  may  have  been  specialized  in  the  aggregate  so  that  it  is  more  efficient 
but  less  easy  to  manipulate  during  integration.  Still,  the  new  ctxnponent  is  available  for 
optimizatum.  When  the  most  “natural”  representation  for  the  new  operations  is  the  new 
comptment,  the  specialized  aggregate  may  not  prove  to  be  diat  great  of  a  hindrance.  There 
are  fewer  choices  available  to  the  software  designer  because  of  die  more  specialized  data 
representation  ami  tqierations  than  in  the  alternatives  discussed  above.  But  the  greater 
number  of  choices  in  die  other  altonatives  may  lead  to  unnecessary  steps  where  the  results 
are  eliminated  later  in  the  process.  For  example,  merging  the  Buf2  comptment  (»ily  to 
eliminate  it  in  the  spedalizatitm  stqi. 

Sonm  of  die  information  in  the  derivation  of  die  original  Systran  can  be  reused.  Whatis 
new  is  the  telarionahipbetwerai  die  new  component  and  tme  existing  component  Oncethat 
is  “bridged,”  computing  die  relationship  of  ^  new  componrait  to  the  rest  of  the  system  can 
make  use  of  previous  doivaticm  (i.r.,  insight  steps,  merging  process,  and  interrelaticmships). 
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Chapter  5.  Interpreting  the  Results  of  the  Editor  Derivation 


Thmslating  into  the  InytoncntatiML  When  translating  the  new  component  into  the 
imptonentaticm,  new  implementations  of  the  operations  of  the  new  component  need  only 
he  derived  (requiring  n  x  /  (m)  definitions).  There  are  no  changes  needed  to  the  existing 
system.  This  method  has  the  fewest  steps  of  all  of  the  alternatives,  but  they  have  the  potential 
to  be  the  most  cmnplex  since  the  software  designer  has  the  least  flexibility  (because  there 
is  less  infonnatkm  available)  and  the  operations  must  be  translated  into  one  and  only  one 
iqnesentation.  There  is  only  one  choice  for  the  data  representation,  keqnng  the  existing 
data  aggregate  representation.  As  with  the  other  alternatives,  there  is  the  potential  for  some 
reuse  of  the  existing  derivation  structure. 

5.2.2  Integrating  Components 

Choices.  As  the  software  designer,  we  made  partunilar  choices  in  defining  the  prototype 
edit-buffec.  For  the  pages  component,  we  set  up  definitions  to  either  merge  the  pages 
comptment  with  the  original  system  or  to  translate  it  into  the  original  system.  Since 
the  regions  component  adds  new  information,  it  must  be  merged.  Since  there  are  no 
dependencies  between  the  mark  and  the  existing  system  it  is  easy  to  add  the  component  at 
either  level  of  original  cmnponents  or  implementatioiL  Since  the  s-expression  component 
does  not  have  ctnnplete  information,  it  must  be  translated.  Howevm;  we  could  have  chosen 
to  cache  the  s-«xpressi(m  posititxis  as  we  did  the  newline  positions,  but  this  would  be 
much  more  complicated.  So  we  chose  a  quick  integration  process  for  the  purposes  of  this 
example,  trading  off  this  optinuzation. 

Cost  Recall  that  the  original  buffer  system  consisted  of  three  components  and  seven 
operations.  Derivations  were  dcme  at  the  aggregation  level  (transforming  the  aggregate  into 
a  prototype)  and  on  the  implementation  level  (transforming  the  prottMype  into  an  efficient 
implementatitm).  The  cost  is  measured  in  the  numbo’  of  data  transfmm  procedures  that 
must  be  defined  in  order  to  integrate  the  collection  of  cmnponents.  At  the  aggregation  level 
there  are  14  definitions. 


n  operatitHis 

m  merges 

nxm 

Bufi 

3 

2 

6 

Buf2 

3 

2 

6 

Bufa 

1 

2 

2 

14 

At  the  implonentation  level  thoe  ate  7  defiitititms.  Using  on  the  order  of  10  dravaticms 
steps  for  each  defirtititm,  tiie  total  number  of  steps  is  q)proximately  210,  with  20  insights. 
The  insights  are  used  for  translating  betwera  the  domains  of  the  dam  representations.  They 
ate  (rften  shared  so  there  ate  in  fact  fewer  novel  insist  steps  that  tl»  (tevel(q)er  must  come 
iq>  with. 

Adapting  die  buffer  by  adding  a  comptment  for  pages  introduced  one  new  ctnnponent 
with  ffitee  operatimis.  The  original  system  had  thrw  cmnpmimits  with  seven  operatitnis. 
This  yields  16  definititms  that  ate  tranfformed  to  obtain  the  integrated  prototype. 


5J.  Seating 
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ncqieratums 

m  merges 

It  xm 

Buf^ 

3 

3 

9 

Bufi 

3 

1 

3 

Buf2 

3 

1 

3 

Bufa 

1 

1 

1 

Total 

16 

'nranslating,  on  the  odier  hand,  yields  9  definitions  that  are  transfonned  to  obtain  the 
integntted  prototype  because  the  existing  q)erations  for  Bufi,  Bufi.  and  Bufs  are  not 
ajQSected. 

5.23  Integrating  Modules 

Choices.  Similar  choices  between  merging  and  translating  using  the  original  system  or 
derived  implanentaticm  exist  at  die  module  levd  as  at  the  comptmentlevd.  Asdiesoftware 
designer, wemadeparticularchoioesindefiningdiepiototypedi^lay-editoa:  Fordiedisplay 
compmoit,  we  chose  to  translate  die  oxnptnent  into  the  existing  buffer  implementadmL 
When  adding  mult^le  buffers  andmultiple  wiiriows  we  chose  to  translate  die  list  and  buffer 
components  into  die  display  editor  in  order  to  prc^iagate  dte  operations  into  die  module  diat 
imports  than. 


Cost  The  cost  of  uring  diis  qiproadi  at  die  module  level  is  similar  to  the  cost  at  the 
component  level  and  can  be  measured  in  die  number  of  data  transform  procedures  duu  must 
be  defined  in  order  to  integrate  die  ooUectiem  of  modules.  In  die  example  screen  caching, 
we  are  in  effect  defimng  alternative  implementations  fordie  buffdoperatimis  in  die  soeoi 
componoit,  so  die  cott  is  diat  of  transforming  a  data  transform  procedure  into  a  functicmal 
definition.  Integrating  die  list  operations  or  a  sinqiler  di^lay-editor  into  a  mote  complex 
diqilay-editar  that  adds  additional  functkmali^  are  simplified  forms  of  die  data  transform 
procedure.  Since  the  aggregate  representation  includes  the  component  representation,  the 
new  aggregate  operation  simply  uses  die  old  comptmentc^eratiem  to  update  die  appropriate 
fields. 


S3  Scaling 

The  benefits  to  snling  occur  primarily  at  die  integration  design  level  Complexly  is 
managed  dnough  abstraction,  modularization,  and  stq>-wise  transformatiem.  The  focus 
of  die  software  designer  is  on  die  design  domain.  These  design  dedsiems  are  translated 
into  dumges  doroughont  die  systnn  at  die  integration  implraiaitation  level  to  integrate 
and  optimise  die  systnii.  The  fbrmalmanqiulatioos  at  this  level  are  goiendly  carried  out 
widiin  local  contacts.  However,  in  order  to  daim  that  diis  method  truly  scales,  automated 
assistance  is  needed  at  die  imegrationimptementatioolevd  in  carrying  out  all  of  die  stqis. 
Most  of  diese  ate  meduudcal  siqps  diat  could  be  performed  with  autcmiated  mipiorL 
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CfupterS.  Interpreting  the  Results  cftheE^r  Derivation 


5J.1  Components 

How  does  the  mediodology  scale  as  die  number  of  compcments  increases?  The  mcamples 
of  adding  pages,  regions,  and  s-eiqiiesskHis  adapt  die  system  by  adding  more  definitkms 
to  the  stt  diat  consdtute  die  existing  system,  and  dien  iq;iplies  the  derivatum  process  all 
over  again.  Only  a  sin^  connection  is  oee^  between  die  new  componmt  and  one  of 
die  existing  components  or  the  data  aggregate.  This  facilitates  adiqitatum,  since,  when  a 
new  component  is  added,  it  is  not  reqniied  to  define  every  possible  connecticm  to  all 
die  existing  subcomponents.  It  dioold  be  sufficient  to  d^K  a  sin^  connecdtm  between 
the  new  conqxmmit  and  die  aggregate.  Only  a  single  compadbiliiy  nuqi  is  needed  (and 
notits  inverse).  This  aids  die  software-develpperw^ien  die  inverse  is  difficult  to  d^ne  or 
die  conqwtibility  nup  is  not  one-to-one.  Of  course,  die  odierinteroonnectums  are  derived 
during  die  im^radon  process,  but  here  is  v^iere  support  from  automadon  and  reuse  can  be 
provided.  Also,  sinoe  we  are  dealing  with  datatypes,  it  is  hi^y  likely  that  there  will  be  a 
Umiied  mimber  of  oonqiooents  diat  make  iqi  die  datatype. 

Candiemdstingsystembecaisideredacmnpoimntasone  way  toscaleup?  Thispos- 
sibiliQr  was  mendoned  briefly  v^ien  we  discussed  merging  or  trandadng  a  new  compcmmit 
with  imidemeataticm  (Section  2.1.1  and  Sectkm  S.2.1).  We  can  treat  die  aggregate  as  a 
component  udien  there  ate  no  interdqiendencies  among  die  fields  of  die  aggregate.  When 
diexe  are  interdependencies,  then  these  must  be  takro  into  account  to  preserve  the  internal 
ctmsistaicy  of  die  aggregate. 

53,2  Modules 

How  does  the  mediodology  scale  as  the  levels  of  module  hierarchies  iDcreases?  Theben^ts 
of  scaling  come  fixMn  using  a  module  system,  in  effect  **scaling  down.’*  Kfodules  he^  us  to 
scale  down  by  Umidng  die  focus  to  one  module  at  a  time  and  its  interconnections.  Peifai^ 
just  as  die  number  of  components  will  be  limited  since  diey  comprise  a  data^pe,  the  number 
of  modules  nouqr  be  limited  if  tli^  comprise  idioms  (rf  a  higher-levd  of  abstracdcm  [80]. 


Chapter  6 

A  Framework  for  the  Module 
IVansformation  System 


Nofw  diat  we  have  seen  an  exanqde  dut  demonstrates  die  derivation  process  and  techniqiKs, 
we  return  to  die  module  transfonnatioo  system  introduced  in  Chapter  2  and  examine  a  more 
liSOKoasdesctqitionofdiepiooess.  Secti(»6.1deacribesdiestq>sinvolvedinusingmodu]e 
tnmafonnations  in  software  devdopoaenL  Ifarms  used  in  the  example  such  as  "componmt,** 
“consistency  relation,**  “aggregate  definition,**  “prototype,**  and  “implmnentation**  ate  given 
a  predae  meaning  and  the  process  of  obtaining  efficient  implementadons  from  a  coUecdcm 
of  components  is  formalized.  Section  describes  die  module  transformation  rules  and 
demonstrates  die  stq»  in  qiplying  diem.  The  findings  ate  summarized  in  Secticm  6.3  which 
describes  srittt  was  added  to  the  framework  and  iriiy.  Providiiig  a  framework  enhances  die 
understanding  of  the  tenns  used  informalty,  provides  structure  to  aid  the  software  designer 
in  using  the  approach  and  is  an  important  stqi  towards  automating  the  system. 


6.1  Module  Ti'ansfomiation  in  Software  Development 

This  section  provides  a  more  rigorous  explanation  of  die  software  devekfanent  strategy 
described  in  Section  2.4  and  demonstrated  in  Secdon  3.1.  The  first  diree  phases  of  die 
procezK  profcam  design,  program  composition,  and  conqiooent  aggregation,  are  eiqplained 
using  a  siinple  dieory  based  on  algebraic  qiecification  t^  provides  a  predse  meaning  to 
constructing  an  aggregate  ^lecification  in  terms  of  components.  Once  a  precise  meaning 
die  qiedficatioo  is  givoi,  it  is  manqmlated  in  die  subsequent  aggregate  integradon  phase 
of  the  process  to  produce  an  agttgate  definition.  Reflecting  on  how  the  qiecificadon  is 
num^iolaied  gives  insigittiitto  constructing  an  algoridundutt  automates  the  process.  The 
final  two  idiases  of  t^gp^ateimpileinentarion  and  opdmizadoo  refine  die  definition  using 
dm  moddb  liaiisforinadon  rules  in  Secdon  6.2. 

As  stated  roriier,  a  notadon  based  on  Standard  ML  modules  [60]  is  used  to  rqnesent 
datatype  de&ddoia.  b  adttion  to  representing  datatype  definitions,  die  notadon  needs 
to  also  express  die  odier  structures  b  die  ttansformadon  prooen.  These  nocadons  are 
introduced  Mdiey  ate  needed  and  summarized  at  die  end  of  die  dupterm  Secdon  63. 
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6.L1  Program  Design 

1V»  start  wiili,  we  need  a  mediod  for  definmg  tbe  datatype  of  intaest,  for  example,  Ae  text 
bnffex,  Algebraic  specifications  are  ea^tecially  iCTroptiaie  because  abstract  datatypes  are 
treated  as  algebras.  Ifoating  datatypes  as  algebras  is  useful  for.  (1)  proving  inoperties 
about  die  datatype  mch  as  consistency;  (2)  showing  die  correctness  of  an  implonmitation 
widi  legiect  to  a  qredfication;  and  0)  uang  logk  to  rewrite  (or  simplify)  equations  by 
suhstitudng  an  eaqaession  widi  an  equivalent  one.  This  does  not  mean  d^  die  software 
designer  must  always  start  with  a  formal  qiedficadon.  hi  actual  engineering  practice,  die 
software  designer  might  use  a  high-levd  prototype  rather  dum  writing  a  qiedfication.  We 
in  foct  followed  diis  qiproach  in  the  devdk)|mieat  of  the  interactive  di^lay-editoi;  since  the 
focus  of  die  software  devdopment  mediod  is  on  integrating  software  components  vriuch 
odres  idace  at  die  system  derign  level  In  dus  duquer,  we  start  with  a  specificatkm  to 
motivate  die  mediod  and  to  enable  ns  to  give  a  precise  meaning  to  the  combinadcm  of 
software  components  into  an  aggregate  datatype. 

^1J2  Program  Composition 

The  first  subset  of  operations  to  be  conridered  is  die  cotistructor  set  [37],  wfakfa  has  the 
property  dua  all  instances  of  the  datatype  (i^e^  all  terms  in  die  algebra)  are  generated  by 
using  only  constructor  set  operations.  Wt  start  by  defining  die  abstract  interface.  An 
abstract  interface  is  simply  a  signature.  Wi  use  a  syntax  similar  to  die  Standard  ML 
signature  dedaiation  to  qiecify  abstract  interfooes.  Por  example,  in  die  datatype  buf , 
dre  operations  createbuf,  ins,  «id  point  constitute  a  constructor  set 

agaatmBOF.si^ 
type  buf 

creatsbuf :  buf 
ins :  ch  X  buf  buf 
point:  buf buf 


This  gives  an  operation  for  creating  die  buffer;  adding  a  new  character  into  die  buffer, 
and  setting  die  focus  <rf  editing.  A  constructor  set  is  used  to  define  udut  I  call  die  core 
component, 

Ustegdreftauneworicandtetminology  of  algebraic  giedfication  of  abstract  datatypes  [32], 
an  S-aorted  signature,  is  defined  for  the  text  buffer  operations  (where  sorts  catrrepmid  to 
types).  The  rignatnre  conrists  of  the  names  ud  functionalities  of  operatkms  over  the  sorts 
in  the  sort  set  5.  CHvenddssignanire,  die  semantics  of  the  text  buffer  operations  is  defined 
by  writii^anti^riaraictpecification  (5,  r,£),  where  27  is  the  5-sorted  signature  and  £  is 
a  setof  r-eqnatiom. 

Dslnifinn  L  A  core  etmponens  spedfcation  is  an  algdvaic  qiedfication 

i*  die  soTt  of  interest,  17can  is  a  signature  of  a 
oonsiniGlor  sec  of  operations,  and  £nN  is  empty. 


tfj.  Mod»iUTnmfome^ninSoft¥iMnD€vekpnmtt 
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Notice  tibat  a  coe  component  qwdficatkm,  sinoe  it  specifies  only  coostmcton,  graierally 
does  not  lunre  any  eqaatioos.  Tliisisaxatba*^oo8e*'q>edficatioaof  abofferanceitdoes 
not  ejqnesa  how  die  buffer  is  initialieBd  or  die  relationship  betwem  die  focus  of  editing 
and  die  text  Sudi  dengn  decisions  ate  defiened  to  a  later  time  whm  the  core  oomptxiait 
is  used  as  die  basis  for  defining  other  componeiits.  Thecorecompcmentisnotmeanttobe 
inqdemented,  its  purpose  being  to  provide  a  notion  of  **equiva]ence”  that  is,  what  it  means 
for  odier  components  to  be  views  or  abemative  mqfiementatioos  of  die  same  datatype. 

Once  a  core  component  is  specified,  we  obtain  other  components  by  supplemmiting  the 
cote  conqxment  specification  widi  additkmal  operations. 

Definition  2.  A  ccmponent  spedfication  is  an  **ratichment”  of  a  core  compo¬ 
nent  specification. 

As  described  in  [37],  an  enridunent  of  a  qiedfication  is  obtaiiied  by  adding  new  (qierations 
along  with  **axioms**  dud  define  die  behavior  of  each  new  operation.  This  is  always  a 
"strict*  exiensioo:  (1)  it  is  non-em]^  (Z)  since  £—  is  mnpty,  there  is  no  change  to  the 
properties  of  the  existing  operation^  (3)  ixme  of  die  existing  operatkms  are  taken  away. 

For  example,  we  enrich  die  buffer  core  cmnponent  by  introducing  die  new  operations, 
move-left,  move-ri{^  and  ahow-char  to  obtain  functionality  for  moving  die  cursor  to  the 
left  or  to  the  risht,  and  for  showing  the  duracter  at  die  cursor  position.  The  signatures 
of  die  operations  ate  listed  first,  followed  by  axioms  dutt  define  the  meaning  die  new 
operations  in  terms  die  core  compontmt  operations. 

atBSturaBOFi  stig 
stracnorcB:  buFc 

move-left :  b J9ue  b Jsuf 
move-rfgM:  B.bu£-»Bi>ttf 
Show-char :  b  J>uf  ch 

axtaimove-lenCBJnaeriCc.d))  «  move-ien(b) 
axkMimove-lellCBpoinKB))  «  b 

mham  move-righKfr)  ■  Bpoint(B) 

asfaeiahow  char(BJna(c,e))  «  ahow-charCB) 
axkaahow-char^poirS(^Jn8(c,B)))  >  c 

sadoei  8how-chai(BpolreCBpolnt(BJn8er<  b))))  ■  8howchar(Bpoint(fr)) 


DefiidtioBS.  A  contpoiiemfifgilementatftm  is  an  inqilemeiitation  of  a  compo¬ 
nent  specification.  Let  P  be  a  ^lecification.  Then  the  particular  way  duu  the 
imidementation  /  satisfies  P  is  described  by  die '*view,”  V :  P  7. 

As  in  [33],  a  view  consists  of  a  mapping  fiom  die  sorts  of  P  to  die  sorts  of /,  and  a  mqiping 
fiom  die  operttioos  of  P  to  die  operatioitt  of /. 

For  exanqde,  we  provide  an  impkanentation  for  die  bofi  oompoomt  qiecification, 
defining  bof  as  a  data  stmcture  consisting  of  an  im^Br(rqnescnting  die  cmsor  or  point  of 
etfidng)  and  a  sequence  of  charactBis(fq«eienting  die  text).  The  operations  ate  defined  on 
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^  (bta  ttnKloM.  ^  nae  a  notatioo  similar  to  tbe  Standard  ML  structure  declaratioa 
CKoqit  ifatt  we  can  it  a  component  because,  unlike  a  structure,  not  aU  die  opearatitnis 
<rf  die  signature  need  be  fanplemented. 


tjpcbuf  •  Buf  of  (int  x  ch*) 

mov»-MICBuf(p,0)  <«=  Buf(p'-1, 0 
nnave-ri(|^u£<i»,0)  BufOi-t-i,  r) 

ShOM^«f»tf(&uf(p,0}  <«=  tlp-i} 

coMtraiBtBttf(p,0  0<p<%t 


The  view  shown  below  defines  how  die  implementation  Bufi  satisfies  die  specificadcm 
BOFe.  Ws  extend  die  notation  to  indude  a  definition  for  views  taken  from  OBJ3  [33]  and 
adipced  to  ML  syntax.  Rrstdieaortindiecofebnfiferisnuppedinto  die  cocrespcmdmg  sort 
Indmoompooeiu.  Then  each  of  die  operadons  in  die  core  is  mapped  into  the  corresponding 
tolerations  in  the  conqxnent 

vim  Vi  frow  BOFc  to  Buf  1  Is 

aortbuf  to  Buf(int  x  ch*) 
vane:  ch 

operaatobuf  to  Buf(p,  []) 

opin8(c,^  to  lctBaf(p,0*-iaBu£(ip,t[..(p-l)]  #[c]#r[p.]) 
oppolnt(-)  to  kCBuf(p,0«~teBu£(p<fl, /) 

cadv 

TTie  subsequence  of  the  sequences  from  the  first  to  die  f*  element  is  denoted  the 
subsequence  of  die  sequence  s  from  die  to  die  last  demmit  is  denoted  s[k.].  The 
placeholder  for  the  sort  of  interest  Qndris  case  buf)  is  denoted-.  This  nett  view  defines 
how  die  implementation  Buf  a  satisfies  die  qiecification  buFc. 

vim  Va  Anon  Bufc  to  Bufa  is 

aortbuf  to  Bu£(ch*  x  ch*) 
wsc:  ch 

spcrsalobuf  to  Baf([],  (B 

apine(p,-)  to  islBaf(|,r)«_lBBuf(i,  (c]#r) 

oppoinK-)  to  fclBu£(/,r)--lBBu£(/#[hd(r)],1J(r)) 


Theconsistencyrelationprovidesaoonespondenoebetweendiedataobjectsmanipu- 
laied  in  one  inqriemeatadon  widi  those  in  anodier. 

MtaMoad.  Let  ^  and  be  component  qiedficationsdMt  are  enrichments  of 
some  common  core  component  ^ledficationC.  Let/(widiviewv/)and/(widi 
viewv/)beinipienieiitationsofPandQretpecdvely.  Thentfaereisacomponent 
eotuiatmj  rtkaUm  bmween  the  terms  in  die  alienaative  imidmnmitations: 

MO  dwp/  Vi(0>Mierer  is  a  r-tenn  in  the  core  component 
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agg 


Hgi]ie6.1:  Projections  of  Ae  Aggregate. 


The  views  Vi  and  V%  sptdiy  dus  ccmsistency  relation  between  the  Buf  i  and  Buf  2  compo¬ 
nents  (d^nedin  Section  3.1). 

In  die  figure  below,  we  see  how  all  of  die  pieces  fit  togetfaec.  The  intersectUm  of  die 
i^xidfications  for  buFi  and  BOF2  is  the  core  qiecification  buFc.  The  ccmsistency  relaticm  is 
defined  impUddy  in  tenns  of  die  views  Vi  andV2. 

(bOFi  (BOT,)  BOFa"^ 

The  consisiency  relations  provide  a  notion  of  consistency  for  the  aggregate  data  objects. 

6.13  Component  Aggregation 

Siqipoae  we  have  a  qiecificatiao  a  core  componmt  Cb,  and  a  collection  of  componmt 
imidemaitatioos  ci,...,Cm  ^i^iere  u  •••  U  «  27^  (i.e.,  every  opention  ^ P  is 
implonented  in  some  oooqKment).  Fmdiei;  for  eadi  pair  widi  1  <  i,  J  <  n  and 
have  diat  n  i7«,  »  iije^  eadi  component  defines  distinct  snlxwts  of  die 
operations).  Then  an  aggregate  is  formed  firom  die  ccdlection  of  componoits  to  provide  a 
refinement  of  specification  ?. 

PetoWonS.  An  aggiegoiejgMdjicatioii  refines  P  by  qiedfying  an  aggregate 
datarqiresentation  constructed  firo  die  data  rgaesentations^diecompoogits 
Cl,...,  c,.  Has  aggregate  rqaesentarion  has  die  fidtowingpropertire; 

•  Hiere  are  prajection  functions,  ptpj„t^iidiiiu4>  an  aggregate  data  object 
toanobjectofoonqx»elltc^  ^  Hgure  6.1  t^iere  n  »  3. 

•  Every  operation  opi  in  component  c^  induces  a  ooneqxmding  operation 
apondieaggiqpte,a.  Theoperationopsatisfiestfaefiollowingeqoations: 
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Hgine  62'.  Aggregate  Operatioo  Defimtum. 


pfp|^op(tf))  -  op^03ro(^a)> 

V*e({l,....Ji}\i^p»pj^a)  mapf  prpit(a) 

prc^opCa))  mapf  prpUoPCa)) 

See  Rgnre  62  ti^iere  n^S^i  •X  •odj  »  2.  Each  operati(»  mi^t 
actually  have  aigiiineiits  odier  dum  the  dare  objjecL 


Nbtkredutt  an  aggregate  ttwgification,5irfiile  it  is  baaed  on  coinponeiitiinpleinentations,  does 
notqnitecopstitnieaniiiq)lcmentationofdie^)eclficationiP,duetotheuseofconsisiency 
reladoos.  Thus,  we  say  dtat  an  aggregate  is  a  n;^iiiemeitf<tfP. 

Cmtinuing  our  CTanq)te  and  taking  move-fHjht  to  illnstnae  die  point,  recall  die  axioms 
for  die  move-right  q)cnaion  in  the  text  buffer  example. 

axiaaipro)i(move-rlghl(e))  >  mova-rfghti(pfoji(e)) 

aiiaaiprciiiCe)  marf  prc^h)  proi|(move-righl(fr))  iragf  probCmova-righK^)) 

aiiaBipn%^)  man  pn^Ch)  pr(^(mo¥e-r1^h))  mare  prDj|,(mova-rioht(h)) 

aiioaiproi,(»)  ma^  prqji(h)  prpi,(rnove-r1^fr))  ma^  proji(move-righK6)) 

The  projecaioa  prpj|  mi^  die  aggregate  to  Buf i.  The  definition  of  move-right  on  die 
aggregate  is  defined  in  tenns  of  die  operadoo,  move-righti ,  ainch  operates  <m  the  ctxnponent 
Bufi.  Ihe  remaining  axkxns  ensure  oonsiatency. 


6X4  Aggregirtefategratioii 

As  tti  httennediatB  step  townds  obtaining  an  implementation  of  die  qiedfication  P,  die 
axiom  dMt  define  die  aggii^aie  qiedfication  are  man^mlated  (eg.,  using  rewrite  rotes)  to 


Pfifinltiond.  Aaag^viaaedpinidoiifeaitfiiieiDentof  anaggr^iate  qied- 
flcaiion.  The  data  repreaentarton  is  defined  as  the  product  of  die  component 
dsmwpreaentations  and  die  operations  are  defined  in  terms  of  the  componmit 
operathm  as  <htta  transform  procedures. 
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Ws  saw  dieae  procedmes  in  die  buffer  dilution  in  Hgnre  3.4  and  extract  die  d^nitioii 
for  move-right  bdow. 

un8pari,(Buf (p,  i,  hr,  (ip,  <p),  ts))  ^ 

Bufi({p  I  P2  I  Ps>,  {»  I  I  b}) 

where  Bufitpa.li)  ■  mapi^,(Bu£a(/,  r)) 

andBu£i(p3,<s)  «  mapi_,(Bu£3((i^,cp},  tr)) 

tai 

unspan,(move-riQhKft))  m(»«-righ^(unspan«(fr)) 


Indeed,  dus  process  can  be  automated.  An  algoridun  for  generating  an  aggregate  definition 
from  a  cdlection  of  components  and  "compatibility  maps”  is  given  later  in  diis  sectitxL 
Tbe  definitions  for  die  operations  of  die  aggregate  axe  in  the  form  of  "data  transfonn 
procedures.” 

Definition?.  A  amipatibifity  mop  is  a  function  that  respects  the  ccmsistmicy 
relation.  Ittranslatestnecompoiiratiepresentationintoanodierrepresentation. 

Depmiding  on  the  oonsisiaicy  relation,  it  may  not  be  possible  to  implmnmit  ctxnpatibility 
nuqis  in  bodi  directions,  but  normalty  it  is  strai^itforward  to  implement  one  of  diem.  When 
a  compatibility  mqi  exists  from  component  Ci  to  Q,  we  say  diat  Cy  can  be  reocfieif  from  Ci,  or 
dutt  a  can  reach  cj.  Here  we  extract  tbe  cmnpatitdlity  nuqi  fimn  Buf  2  to  Buf  1  (Figure  3.4). 

map,^,(Bu£a(/,r))  ^  Btt£i(#/,  /#r) 

We  define  alteraative  ingtonentations  on  data  rqaesentations  widi  "data  transform 
procedures,”  in  tenns  of  die  original  implerngitations  and  "translatitm  iimcticHis.” 

Definitions.  A  irniistojanyimciion  is  a  fimetion  dud  translates  one  data 
rqnesmitation  into  anodier  rqiresentation. 

The  planning  functions,  span,  and  its  inverse,  unspan,  and  compatibility  mi^  are  all 
examides  of  trandation  functions. 

Definition  9.  A  data  trwufimn  procedure  defines  an  alternative  implmnmita- 
tion  and  may  take  one  of  two  forms: 

1.  OivenapeogramfnsingadatarqireseatationD  and  an  injective  fiincticm, 
span,  that  translates  dnnents  of  the  data  rqnesrotation  D  to  elmnmits  of 
^  data  rggesemation/y,  we  define  fas: 

t(span(4»  ^  apafKKd)) 

(widi  universal  dosure  over  occurrences.) 


94 


Chapter  6.  A  Framework  for  the  Module  DraiufarmaUon  System 


NODES  <B  the  Mt  of  dl  tbe  oonfMocott. 

tfaeietofantheconyatfliflityin^ 

ItetMh  c  that  it  a  Gompooeot 
MCm  {c},  NmNODES-Cirn 

fhraidi  tip  that  is  «  openaiao  defined  in  tt>e  ooGBpooeot  c 
whOeiV^I 

3jec,f  eN,mapj^  eMAK  «=» 

C*»CU{/}; ‘'botpiitdaiatransfanniisiiigspan”^  C»C'; {/} 

3J€C,/ €iV,  ma(y^y€MAl*S  «=» 

C'«CU{/}:  “ootpot (fatta trapafocm using nnspan";  C^C;  Ns^N-if} 


Hgure  6.3:  Generating  Aggregate  Definititns 


2.  If,  instead,  there  is  a  surjective  fiinctkm,  unspan,  diat  translates  dements 
of  the  data  iq;nesentation/>'  to  elemoits  of  the  datarqnesratadtnD,  we 
define  fas: 

unspancfcd))  ^  f(un8pan(4)) 

Notice  die  similarity  with  Definitions  1  and  2  presented  in  Sectum  2.2  (where  die 
domains  are  now  data^^ies).  This  form  of  definition  is  called  an  “expression  procedure” 
in  [74,  75]  since  an  expresrion  appears  on  the  lefdiand  side  of  die  procedure  definitim. 
These  two  definitions  give  meaning  to  f  <mly  whmi  it  is  q^lied  to  the  result  oi  span,  or 
when  unspan  is  qiplied  to  its  result  We  idy  tm  qiplying  syntactic  transfotmadcMis  to 
obtain  a  functional  definition  for  die  program  f  <»  die  data  rqnesentation  O'.  The  span 
function  must  be  injective.  Odierwise  f  may  not  be  able  to  distinguirii  distinct  values  duu 
f  could.  The  wspan  function  most  be  smjective.  Odierwise  there  could  be  some  values 
defined  on  f  but  not  on  f;  dierefore,  f  would  not  be  a  valid  implemmitati<m  of  f  because 
it  could  not  handle  all  values  diat  f  could.  Data  transform  procedures  are  used  to  eiqilain 
die  module  transformation  rules  diat  affect  data  rqiresentations,  shdi*  translatey  and 
expose). 

Now  we  examine  die  algoridun  for  generating  an  aggr^ate  definition  and  see  how  it 
preserves  die  properties  of  die  axioms. 

An  A^oiltlim  lor  Gcncrtfiiig  Ddfaiitk»s 

The  alforidim  for  generating  definitions  in  Figure  63  is  based  on  directed  gr^di  con- 
nectivi^  where  nodes  of  die  gia{di  are  merged  with  the  qiplkatuin  of  die  integratimi 
nansfonnations.  Consider  die  collection  of  componoits  and  compatibility  miqis  as  a  di¬ 
rected  graidi,  triiese  die  componans  oe  nodes  and  die  compatibility  maps  are  directed 
arcs.  Eett  operation  of  every  component  is  considered  in  tmm  widi  die  goal  of  produc- 
ing  the  corresponding  aggr^ate  operation.  The  node  iqaesenting  die  comptmoit  under 
conrideration  constitutes  the  com.  AH  nodes  diat  are  connected  to  some  no^  widun  the 
core  (via  an  arc)  constitme  dsefiander.  The  nodm  in  die  firontier  are  "coatesced”  widi 
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tbe  core  by  eiqiaadiiig  Ae  cere  to  inclnde  die  nodes  in  die  frontier  and  inodudng  the 
aggregate  operatkm  definition  using  a  variant  of  die  data  transfonnatic»teduuqiie.  This  is 
done  separately  far  nodes  in  the  fiontkr  diat  can  be  readied  from  a  node  in  die  core,  and  for 
nodes  in  the  frontier  tiiat  can  reach  a  node  in  the  core,  since  different  data  transfonnatum 
definitions  are  required.  Then  a  new  frontier  is  defined  based  (»  die  eiqianded  core  and 
the  process  of  coalescing  connected  nodes  is  rqieated  until  all  the  nodes  comprise  the 
core.  Then  die  whole  process  is  rqieated  until  all  die  qieratunis  of  all  die  ccmiptHiaits 
are  leimplemented  in  the  data  aggregate.  Here  we  see  the  process  for  makebuf  defined  in 
component  Buf  2.  The  aggregate  operation  definitions  diat  are  produced  are  shown  below 
the  gnqdi  as  it  is  coalesced. 


makebufixi  sparKmakebu^ 
«pan(Bu£a(/,r))  ^ 

Bu£ixa(P.  t,  it  r) 

where  Bu£i(p,0  ** 

mapj^jCBuftd,  r)) 


un8pan(makabu()  <s  makebufixa 
im8pan(BMf(p,t,l,r.ilp,g>).ts))  <= 
Bufix2({p  I  Ps),  {t  I  h),  I,  r) 
where  Bu£i(^,/3)«: 

map,_,(Buf3((ft»,q»>,  0)) 


The  data  transform  tonplates  (shown  bdow)  are  used  to  generate  die  **code”  for  die 
aggregate  definition  operations.  The  fixed  **code**  in  the  templates  is  in  bold  face.  Place- 
hedders  (eg.,  op,  to  be  filled  in  witii  die  operation  name)  are  in  itaiics.  Once  instantiated, 
die  templates  produce  die  data  transform  procedure  definitimis.  The  auxiliary  fiinctitm  n 
takes  a  set  and  returns  a  literal  tag  conqxised  from  its  elements.  This  is  used  as  a  unique 
and  descrqitive  subserqx  for  die  intermediate  aggregates  diat  are  built  as  the  nodes  of  d» 
gnqdi  are  coalesced.  Tte  function  Ptidees  a  set  and  builds  a  literal  parameter  list  out  of  the 
demmits.  This  is  used  to  create  unique  variable  names  for  die  parameters  the  aggregate. 


load 

•P«e(A«ir<oWO))  Aair«:o(#(0) 

where/  - 
hi 

<!Pirico(aPM(A«ir<o(#(C))))  ^  •l«(<Pi«o(Al|ff(o(W))) 


DataThmsform  Tbmplate  -  Spart 

When  an  arc  (and  dms  a  oooqpatibility  nuqi)  easts  from  a  node  in  the  core  to  a  node  in 
the  frontiei;dieaapan  is  used  to  map  die  data  representation  of  an  aggregate  consisting  of 
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the  nodes  of  the  coie  into  an  aggregate  c(»sistiiig  of  die  nodes  of  die  core  and  die  frcxitiec 
The  span  fonctk»  uses  die  comjMtdbilily  mqis  to  define  how  the  data  representatuns  of 
die  nodes  in  die  frontier  are  generated  tiio  data  representati(»  of  a  node  in  the  core. 

■“P^AggjKcoWO))  ^  I  /  }])) 

where/  » 
hi 

Mpaii(<vzr(Po(Af«ir(poWO)))  <=  opffiCiiwu9n(Aun(c^WlC%) 

mi 


Data  Transform  Template  -  Unspan. 

Whmi  an  arc  (and  thus  a  compatibility  mqi)  exists  from  a  node  in  the  frontier  to  a 
node  in  die  core,  then  unspan  is  used  in  die  defimtum  to  map  the  data  representatum  of  an 
aggregate  cooasting  of  the  nodes  of  die  core  and  die  frontier  into  an  aggregate  ctmsisting 
of  die  nodes  of  the  core.  (We  call  it  nnspan,  since  it  qians  in  the  qiposite  diiectimi  of 
how  we  are  building  the  aggregate,  that  is,  from  core  to  core  and  finmdet)  The  unspan 
function  uses  die  omnpatihility  mqis  to  define  Imw  die  data  iqxresmitations  of  the  nodes  of 
the  core  are  generated  from  a  data  iqpresaitation  of  a  node  in  the  frontim;  using  die  notatimi 
{  Cl  I  e2  }  to  denote  that  a  value  is  computed  in  more  dian  one  way.  V/t  use  B[x\exp\  to 
mean,  iqdaoe  all  occunences  of  jc  in  A  with  exp.  The  notation  needs  to  be  supplemented 
in  dus  manner  because  multiple  ways  to  compute  a  value  must  be  maintained  to  ensure 
consistency  among  the  conqxnents. 

A  number  of  simplifying  assumpdons  have  been  made  for  this  presmitation.  Only  one 
component  in  die  frontier  is  merged  at  a  time.  This  result  can  be  generalized  tt>  merge 
a  collection  of  nodes  in  die  frontier  with  the  core.  The  definition  in  Hgure  3.4  uses  dus 
q^xoodiwfaereapancOoatesoesBuf2andBu£3togedierwidiBufi.  This  algoridun  treats 
die  aggr^ate  data  structure  as  die  product  of  the  componaus,  maintaining  the  compcment 
abstnetians.  fri  Hgure  3.4  dw  abstractions  are  lifted;  die  data  structure  is  the  product  of  the 
folds  of  die  components. 

A  Devdopngent  of  the  Aggr^iatc  Definition 

In  Older  to  diow  diat  die  aggregate  definitioo  satisfies  die  aggregate  specification,  we  start 
widi  die  ^lecification  and  useaconstructivctyiaoach  in  developing  die  aggregate  definitiCTL 
The  naming  example  consists  of  dnee  artntraty  conqpooents  (which  “rqiresaif*  die  same 
object),  and  we  consider  the  case  where  die  opersdoo  is  defined  in  die  secmid  comptment 
Three  components  are  enough  to  consider  all  of  the  various  integration  possibilities.  The 
aggr^tate  qiedfoation  is  defined  using  axioms  in  Hgure  6.4. 

The  first  diree  axioms  declare  that  diere  are  consistency  relations  among  the  components. 
The  next  axkxn  defines  die  behavior  of  tibe  operation  on  the  aggregate  datatype  in  terms  of 
dm  second  component  The  nmudning  three  axkxnsennirediat  after  qiplying  die  operation, 
aO  of  the  coniponents  remain  consistent  There  is  such  a  set  of  axioms  for  each  operation 
defined;  for  iHustrativt  purposes  only  one  set  is  shown. 
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proj, :  agg  -» ci 
proj2 :  agg  c* 
praj, :  agg  cs 

C2  X  Cl  — *■  bool 
03  X  C2  — *  bool 
C3  X  Cl  — » bool 

«*«proi2(c)  mart  pn)ji(c) 

«»o«prQis(c)  «»«art  prokCc) 
axtemproisCc)  ma|4  proj,(c) 

«*««prob(0P(a9g))  -  opj(prpj2(agg)) 

«lo«pfpi2(agg)  mart  prpj,(agg)  prpb(op(agg))  mart  prpii(op(agg)) 

axiom  prpj|,(agg)  mart  pn^(agg)  praj3(op(agg))  mart  projjCopCagg)) 

axiom  prpjjCagg)  maf^  pro], (agg)  *=►  probCopCagg))  map|  proji(op(agg)) 


Rgme  6.4:  Aggregate  Specification 


For  any  aggregate  definitirm  of  the  data^pe  diat  we  d^ne,  we  must  ensure  duu  it 
satisfies  these  axioms  (diat  comprise  die  aggregate  specification).  We  start  with  a  very 
simple  definition  (Hgute  6  J)  diat  assumes  we  have  fiii^onal  miqipings  in  either  diiecticm 
betweoi  any  two  ccMnponmits.  Thai  we  generalize  die  result  a  litde  more  to  make  it  easier 
for  the  designa  to  define  die  datatype,  fii  Hgnie  6.6  we  relax  die  restriction  diat  requires 
compatibility  nuqis  in  either  ditec^  betweoi  any  two  ccmponents,  to  requiring  a  single 
compatibility  mrq>  in  mte  directioo.  In  Figures  6.7, 6.8,  and  6.9  we  relax  die  restrictirm  that 
requires  any  two  components  to  be  directly  cmmected  to  simply  requiring  a  cmmectirm, 
possibly  th^gh  smne  number  of  intetmediaie  components.  We  will  see  that  care  must  be 
taken  whoi  dealing  widi  many-to-one  compatibili^  maps.  Hnally  we  produce  a  definitirm 
(seen  in  Hgute  6. 10)  that  allows  us  to  explrtt  the  interdependoicies  among  die  components 
for  optimization  purposes.  This  is  the  definition  diat  is  used  in  die  algoridim. 

We  take  a  constructive  qijaoach  by  showing  how  to  transform  the  axioms  into  the 
definitum.  Eadi  section  introthioes  a  ddKnititm.  The  proof  details  on  how  it  satisfies  eodi 
of  the  aximns  ate  crmtained  in  ^ipendix  E. 

FtroductoftheRqiresentatioiis.  We  start  off,  for  the  sake  rtfeiqiediency,  by  defining  the 
rqnesentation  erf  die  data  aggregate  as  die  product  die  emnponenttepresentatiems, 

tjft  agg  ■  Agg  of  ci  x  C2  x  cs 

and  die  operations  as: 

op(agg)  «=  prpj,“‘(op/pfO|^agg))) 

Tltis  d^nition  is  dqiendent  on  die  ability  to  define  die  cmisistaicy  relations  as  a  pair 
of  fbnetions  miq^g  firom  one  refnesentation  to  anotha  and  vice  versa.  The  ccmsistency 
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<Hvauopi,  mapi^a,  »naPi^s. 

mapi^j, 

local 

praii(Mr9(ci,c2,c3))  «=  C2 

pfpE-»(r)  4=  Agg(inapj^,(x),  z,  map,^j(x)) 

ia 

op(agg)  <=  prpE-*(op2<prola(agg))) 

cad 


C2 


Cl 


Hgure  6  J:  A  Simple  Definition 


xelatioo  X  mapf  y  is  darned  using  a  pair  of  c(niq>atilnli^  maps  as  x  =  map,_^Cy)  and 
y  s  mapj_^(x).  Tto  requires  that  each  cogq>atibOitymip  has  an  inverse  since  the  aggregate 
must  be  able  to  be  generated  from  any  cmnptmenL  Thm,  taking  the  projectitm  is  simply 
extracting  the  qqxopriate  field,  for  exanqtle,  prpj2(Agg(ci,  C2,  C3))  -  C2.  Thlting  the  inverse 
projection  is  simple  as  well,  sinoe  the  aggregate  is  easily  generated  from  any  component 
since  tiiere  are  mappings  defined  from  any  compcment  to  all  tiie  otiters. 

^  start  with  tiie  axiom  defining  the  behavior  of  tite  aggregate  operatimi  and  qtply 
transformations  to  obtain  a  functional  definitkm  fmop. 

probCOpCagg))  «  OpjOarohCagg)) 

We  take  the  inverse  projection  of  each  side,  (we  must  tiiow  that  projj*  is  injective) 
ProE’‘(tiroi2(op(agg)))  -  pn^‘(OPi(proi2(a99)» 

and  tiien  simplify  (we  must  show  tiuuprpj^^  is  a  left  inverse  <rfpraj2). 
op(agg))  «  prpf‘(Opii(pfDi2(agg))) 

Qrmqring  all  the  definitions  togedier  we  get  the  d^nititn  shown  in  Figure  6^.  The 
components  and  tiie  compatibility  nups  tiiat  are  givoi  are  dqncted  to  the  li^t  of  the 
definitions  (in  tiie  figure).  Comptments  are  depicted  as  nodes  labded  witii  die  name  of  the 
comptmoiL  (Compatibility  mqis  are  depicted  as  directed  arcs. 

Rciiiqdaiieitfiiig  the  Opcratkms.  W»  would  like  to  relax  tiie  restriction  that  requires 
oompatibOify  mips  in  botii  directioos  betwemi  any  two  components,  to  merely  requiring 
a  single  compatiWlity  nup  in  one  direction.  Thm  are  two  cases  to  consider,  for  eitiier 
function  that  is  renuwed.  Tbeoonastency  rdationx  map(  y  is  defined  uang  (me  or  the 
otiier  oomi»tibil^  nup  as  x  «  tn8p/_i(y)  or  y  »  nriapj_^^(x).  Recall  tiiat  it  is  possible 
to  define  a  new  implementation  of  an  operatkm  given  a  compatibilify  map.  When  tiie 
functkm  translates  from  the  oldrqxesentation  to  the  new  we  call  it  "span”  (since  it  spans 
rquesentations).  We  have  die  following  dilution  for  op': 


S^CipanOd)  apan(op(^) 
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CSfCKop,,  mapi^„  map,^ 
loed 

opj(fnapi,^,(c2))  map,^,(op,(ca)) 
map,^2(o^(c3))  ^  op2(map^,a(<!j)) 

la 

op(A9g(ci,C2,C3))  •«= 

AgsKcJ.  <4,  cj) 

atec  cj  ■  0Pi(ci) 
aadc^  «  opaCoi) 
aadc^  -  opjCcs) 


Hgnre  6.6:  Product  of  die  Operaii(»s 


Wtim  die  fdnctioa  translates  finom  die  new  representation  to  the  old,  we  call  it  *‘unspan.’* 
'Wd  have  die  following  definition  for  op': 

unsparKop'Od)  <«=  op(unspanCc)) 

One  way  to  implement  the  aggregate  is  to  use  as  a  lepresoitatitxi  an  n-nqile  of  the 
rqaesentatiops  of  die  various  components.  Then,  die  operations  are  d^ned  over  diis  n- 
topte.  Consider,  for  exanqile,  a  component  cj  in  vduch  the  operatkm  opj  is  defined.  We 
devek^  coneqionding  implementations  of  diis  operation  for  die  other  cmnponents  by  using 
data  transform  prooednres. 

locd 

opik(map^c/))  map^opKc/)) 

la 

op(agg(...,c/,Ck,...))  ^  Agg(...,cy',  cn',...) 

whwecy'  -  opKcy) 
aadcjk'  >  opi(cft) 


Ntere,  data  transform  procedures  allow  us  to  define  opj^  as  an  alternative  implemmitatimi 
of  opi  on  die  data  representation  <rf  c*.  lb  do  dus,  we  dqimid  on  a  con^patibility  mq>, 
mapy_A,  firam  c/$  representation  into  c^’s  rqaesentadon.  If  we  had  die  inverse  instead, 
we  use  die  odier  form  of  die  data  transform  procedure.  The  compatihility  mi^,  mapy_ji, 
respects  die  consistency  relation,  map^. 

Using  diis  qiproach  in  our  exampl^  if  we  ate  givoi  die  operadtm  op2,  and  compatibili^ 
nuqps  between  die  second  component  and  eadi  of  die  other  componmits,  we  d^ve  new 
imptemeatatioos  of  die  operation  for  die  odier  componmits  using  the  data  transform  d^ni- 
tioos.  Then  we  d^ne  the  operation  on  die  aggregate  in  terms  of  die  component  operations, 
udiere  eadi  component  operation  iqidates  the  ^ipropriate  subcomptments  of  die  aggregate 
(see  Figure  6.6). 

The  definition  for  opi  demonstrates  die  use  of  a  span  function  since  map2_t  translates 
firam  die  old  representation  to  the  new  representation  in  dus  case.  The  definition  for 
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op^  demonsinUBS  die  use  of  an  unqum  functkm  since  map3_2  trandaies  fiom  die  new 
wpesentidop  ID  iiieoldie|Mesentatk»  Indus  case.  Un]ikBdieia«viousdeBnition,wliexedie 
defining  coinpoiieitt  was  translated  into  eadi  of  the  odier  components,  here  we  are  actually 
defining  operations  for  eadi  of  die  odier  components,  tf  dteqifsopriateconqiatibilitynu^ 
is  ayailaMc,dien  we  have  a  dioice  between  translation  and  derivag  a  new  operation.  Tb 
compute  die  new  value  of  ci,  for  example,  we  know  how  to  translate  between  C2  and  ci 
and  can  define  as  inap2-»i(op2(c2))<  Alternately,  we  can  derive  a  new  operation,  opj,  to 
compute  die  new  value  rfc'i  using  opi(ci).  Since  diere  is  no  compatibility  mqifixMnca  to 
C3  we  have  no  dioioe,  but  must  derive  a  new  function  to  compute  die  value  for  C3 . 

In  dus  simpKfied  presentation,  we  cannot  get  die  result  riiown  in  die  Imffer  example, 
udiere  the  cursor  in  Buf  1  is  computed  in  tenns  of  die  sequences  of  lines  in  Bufs,  since 
components  cannot  interact  Wt  see  later  how  to  obtain  dus  result  (seen  in  Hgure  6.10). 
But  first  we  deal  with  die  restiicdon  that  dus  definition  is  only  qqplicable  tiriimi  all  the 
components  are  directly  connected .  Wb  would  like  a  definition  that  is  also  tqiplicablewhai 
componoils  are  indirecdy  connected,  through  some  number  of  intermediaie  compcments. 

Showing  IWuiaitivltyL  ^wooldlikBtordaxdierBStrictionduurequiresanytwocam- 
ponents  to  be  dhecdy  connected  by  a  compatibility  nuq>,  to  simply  requhing  a  connecticm, 
possibly  dirongh  some  number  of  intermediate  componmits.  ^  must  be  careful  to  mcdude 
intermediates  diat  lose  information.  For  example,  die  tranriation  from  a  component  diat 
represented  a  buffer  as  text  into  a  component  duttrqaesented  die  buffer  as  s-expressions 
loses  information  about  whitespace  and  newline  positicms.  These  were  automatically  ex- 
duded  in  the  previous  definitions  because  we  cc^  not  write  die  required  compatibility 
miqis.  Now  dtat  we  are  not  required  to  write  mqqpings  in  all  cases,  we  must  be  carefoL  Wb 
can  rilow  many-ttK»e  nuqipings  on  die  firinge  of  the  compooent  gnqih,  but  not  widiin  it 
^where  they  might  act  as  an  intermediate. 

Sity  we  are  given  a  direct  oonqwdbQity  mq)  b^ween  C3  and  C2  uduch  we  use  to  define 
op3.  an  alternative  implementation  of  opa  for  compooent  03.  'Vife  would  like  to  r^lace  dus 
compatibility  rngp  by  a  comparihilitymqibmwetgic^  and  some  intermediate,  say.  Cl,  and  a 
conqiatiMlityiniqi  between  ddsmtermediate  and  Cain  die  context  of  defining  opj.  Thereare 
four  cases  to  consider  dqiending  on  vdddi  way  die  conqiatibilitymqis  are  defined.  These 
cases  can  be  iterated  for  arbitrary  padi  lengths,  hi  all  cases,  we  derive  die  new  operation, 
0P2,  by  first  obtaining  an  intermediate  operation,  opi,  for  the  interntediate  componenL 

1.  Given  die  translations  g ;  ca  -*  ci  andfitci  03,  we  d^ne  die  relation  betwemi 
C3  and  Ca  as:  h(g(b)) »  c,  and  define  opj  as: 

agj(rio3))  i(oft(Qa)) 

OBi(*(ci))  *(op,(ci)). 

Recall  dieexam|defitDm  Figure  6.6.  If  we  did  not  have  die  direct  connection  betwewi 
03  and  Ca,  irav>|_^»  bntradier  mapi^,  dien  opi  most  be  defined  indirecdy  in  terms 
of  flpi,  vAidi  in  ton  must  be  relirted  bode  to  op^  vdiere  die  operas  is  originally 
defined  (see  Figure  6.7). 
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QIuukooi,  mapi^i,  map,^ 


oaL("»Pi-i(c»))  mapj^,(op,(ca)) 
5&(»napi^(cO)  <=■  map,^3(op,(ci)) 

IB 

op(a9g(ci,ca,C3))  «= 

Agg(<^,  cj,  cj) 

wkcKci  -  op,(ct) 
aad  a  0P2(O2) 
and  cj  a  aps(c3) 


C2 


Cl 


Hgiire6.7:  Thmsitivi^ — Case  1 


2.  Given  the  translations  ; :  ci  -»  ca  and  A :  cs  -*  ci,  we  d^ne  the  lelatiim  between 
C3  and  C2  as:  g(h(c))  »  b,  aodde^  ops  as: 

«(0Pl(ci))  ^  opj(s(ci)) 

*(o^(c3))  <=  op,(*(os)). 

This  is  similar  to  Case  1. 

3.  Given  the  translations  g :  C2  ci  and/i:  cs  ci,  we  d^ne  die  relation  between 
C3  and  C2  as:  gia)  >  Mcs).  and  d^me  op]  as: 

^(sio^)  ^  a<0Pi(ci)) 

*(0^(C9))  <=  0Pt(A(C3)). 

RecaU  the  exanqde  from  Hgore  6.6.  Ifwedidnothavemap)_«2^**i^'^'^^*P3-»i> 
dien  opj  must  be  defined  in  toms  of  opi,  ii^iidi  in  tnm  must  be  related  back  to  opa 
ti^ieie  die  operatioa  is  originally  defined  (see  Hgore  6J). 

Our  system  mmt  remain  oonsistem,  so  we  ocorider  die  possibili^  udimi  die  inter¬ 
media^  oompooent  loses  infonnation.  In  diis  case  our  equatioo  does  not  express 
our  imention  of  oonaaency.  Ihke  for  exanqde,  die  s-expcesskm  cooqioiient  'Wt 
easity  define  compatibility  nups  from  Buf  i  to  Buf«  and  from  Buf2  to  Buf«.  Each 
oomparihility  mqi  loaes  infonnation  about  whiteqiaoe.  ^  cannot  combine  these 
two  oonqmtttiili^  maps  to  obtain  one  dial  trandates  between  Buf  i  and  Buf2.  yVt 
must  add  the  constraint  diat  die  cooqiatibiliiy  maps  be  injective.  do  not  have 
to  introdnce  diis  constraint  to  die  odier  cases  because  we  are  not  i^le  to  define  die 
retpiired  comparibiliQf  mips.) 

4.  Given  die  translations  ft  ci  C2andfi:  ci  cs,  we  define  die  relation  between 

C3aiidc2as:  3x:cif^)«C2aiidli6t)«c3,andd^beop3as: 


f(ae^(oi))  opsC^ci)) 

ogijWci))  a(op,(ei)). 
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Ohms  oPi,  maj^i, 


0Pi(miPi^i(ca))  maj^|(op,(<sa)) 

map,_,(oa(«a))  <=  op,(map^,(<s,)) 

op(agg(ci,c2,C3))  «* 

AggCcJ,  c^, 

o{  ■  Op|(ci) 

«^ca  »  orh(ca) 

•Bd  <4  ■  OPl(Cs) 


Hgine  6.8:  Thmsitivity — Case  3 


GHwuopi.  maPi^j.  map,_j 


locai 

w»Pi-.a(2ELCc>))  <=  op,(maft^a(ci)) 
o^(map,^j(ci))  <=  map,^(op,(ci)) 

hi 

op(a9g(ci,C2,cs))  -«= 

A99(ci,  ej, 

whara  cl  •  op,(ci) 

•^<4  -  0Pi(<!a) 
aiidcl  -  op,(cj) 


02 
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Hgiire6.9:  Transitivity — Cased 


Hoe  wt  have  a  difierent  set  of  nuqiping  functiaiis,  but  again  opj  muft  be  defined 
in  lenns  of  opi,  viuch  in  tnni  most  be  related  back  to  0|>2  siAtat  die  operation  is 
originally  defined.  Thisresnltsinanewdefinitiooof  op(seeRgnre6.9). 

IncremaitaHyBiiihBng  the  Aggregate.  A  nuxe  flexible  approadi  is  to  arrange  for  aU  of 
die  oompooent  representations  to  be  available  for  die  operation  definitioos  in  order  to  take 
advaittage  of  any  intenelatinnshipsaniong  die  varioos  representations.  Then  we  cKininate 
die  restrictions  seen  in  Hgnre  6.6  t^iere  oomponait  fields  that  make  iq>  die  aggregate 
rrpreatntation  could  not  interact  Going  back  to  diisprevioos  aggregate  de^tion,  instead 
of  actnally  deriving  implementations  for  die  component  operations,  rqgesented  by  opt,  die 
data  tranafoim  procedure  itself  is  symbolically  manipulated  to  yidd  a  new  defidtion  for 
the  aggregate. 


tfj.  Mab^TiwvfimnationinScfiwanDeveU^mieHt 


1Q3 


hNd 

•  •  *  ^1^  ^  •  •  • 

fa 

ogCtparKcy))  <=  8pan(op,(cy)) 

This  it  accomplished  by,  in  effect,  unfolding  the  component  opention  d^initioos  within 
the  bo^  of  the  aggr^ate  operation.  The  abstraction  boundaries  of  die  components  are 
lited  m  fedlitBiB  improveniGnts  in  the  effidency  of  die  aggregate  data  representation  and 
operations.  Theban  function  is  abstracted  from  die  definition  fornotadonal  convenience, 
and  to  put  die  definition  in  the  proper  form  formanipulation  as  adata  transform  procedure.  K 
we  had  the  inverse  compatibility  nuqi  available,  then  die  unqian  form  of  die  data  transform 
prooedme  is  used  insteal 

Wb  think  of  this  process  operationaUy  as  incrementally  building  the  aggregate,  rqiCTt- 
ecdymeil^ngacyaoent  components  until  die  sinp^  aggregate  is  left  The  definitions  of  die 
operations  and  qianning  functions  are  obtained  medianically  by  considering  die  order  in 
wlddi  the  oonqionents  must  be  "metgel*' The  basic  idea  is  to  conshier  die  buffer  definition 
u  a  grqdi,  vriiere  the  components  are  nodes  and  die  compatibility  mqis  are  directed  arcs. 
The  operations  for  eadi  cooqmnentmuq  be  reinqilemented  to  operate  on  die  new  aggregate 
representation.  This  is  done  in  stages.  Starting  at  die  node  r^resendng  die  component 
adiere  die  operadons  are  defined,  aU  connected  nodes  are  merged  into  a  new  “coalesced” 
node  using  a  variant  m  the  data  trantformation  techniques.  This  coalescing  of  connected 
nodes  is  rqpeaied  until  die  grqdi  coUqises  into  a  sing^  node. 

Returning  to  our  exanqde  (see  Rgnre  6.1(9,  we  start  with  the  given  definition  for  op^. 
We  meqie  die  second  component  (vriiere  the  operation  is  defined)  widi  die  adjacent  first 
component  to  obtain  an  intermediatr  operation  opi^s*  Iben  we  merge  dus  intermediate 
aggregate  widi  die  now  atHaoenttfairdoonqionemtoobtain  die  operation  op  on  die  abrogate 
data  structure.  Notice  that  qmn  and  unapan  are  being  imwkhiced  eq^ddy  for  die  first 
time.  In  die  previous  sections,  die  coaqwtibility  mq»  served  inqdicidy  in  diat  capacity. 
However,  die  eaqaessions  here  are  more  complex  so  that  qian  and  unqian  functions  must 
be  introdnoed  in  order  to  get  die  eqaenioiis  into  a  form  dutt  we  know  bow  to  manqinlaie. 

These  ate  precisely  the  gum  and  unqian  (lefinitinnsiisrd  in  the  algoridun  presented  at  die 
bqdttningofdiissectioiL  Tliqrsatisty  die  properties  given  in  Definition  9.  By  construction, 
tteqienfimction  is  goaratoeed  to  be  injective.  Since  die  componmit  argument  appears  in 
die  aggregate  result,  diea  two  distinct  components  alwtys  yidd  two  distinct  auregates. 
Also  by  oonsttoction,  die  unapan  function  is  guaranteed  to  be  surjective.  Since  die  fields  in 
die  aggregate  result  are  a  sttbM  of  die  fields  in  die  aggregate  argument,  dien  every  dement 
of  die  result  is  hi  die  image  of  unapan. 

d.L5  Aggregste  Impleiiieiitation 

CWuhidiig  dfaiinpieineniation  of  die  qpecificationP,  die  data  transform  procedures  from 
the  aggrqqfe  definition  are  ttansfbrined  into  fhnetiond  definitioiis  to  yidd  an  aggregate 
pjifliotype. 
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OheKepi,  map^i,  map^, 


•P«n(oa>  ^ 

ilggiCet,  oi)iAacci  ■  ma|]^_|(c2) 
unipan(a9g(ci,02,cs))  <= 

Aggi({  Cl  i  map(|_,|(Qs)  },  ci) 

opi^tpin(ca)) 

•panCop^Cea)) 

unipin(oe(ik9g(ci,e2,cs)))  ^ 
ap,„2(un8pan(&gg(ci,  Ca,  cs))) 


r - Tap 

A  *  i 


Rgare  6.10:  bcremental  Moging 


DdUtfoBlO.  Anaggr^alB/mMOOpeisaiefineinaitofdieaggregated^iii- 
tioo  where  the  data  trMuformpnx»dnre«  have  been  transfcymed  into  functional 
definitkios  to  prodnoe  die  fim  exBcotabte  ^yston. 

We  law  an  exanqde  of  a  prototype  Imfler  in  Rgare  3 


6.1.6  Optfanizatioii 

The  funcdooal  defimtioiu  of  die  aggK^ate  prototype  are  father  refined  for  optimization 
pugweei  to  yield  an  aggg^ltte  implementation. 

IMWIIobU.  An  aggg^ateieytoiiewaitioii  is  a  refinement  of  die  prototype 
providini  an  “efficient”  impiementarion  of  the  datatype. 

andtnvnlvM^  fnrCTanip^  tradeniffg 

between  die  amonnt  of  spect  die  prognun  niei  and  the  time  required  to  run  die  program. 
TVfe  law  an  exaaqde  of  an  optimized  bufier  in  Rgure  3.6. 

6J2  Module  TVansformation  Rules 

This  section  providea  a  more  ligorons  exphmation  of  die  module  transfonnation  nika: 
tnuakae,  sfiff);  expou,  ittcorporau,  and  release.  Hi^  were  initially  presented  in  Sec¬ 
tion  23;  die  reader  mity  want  to  refer  bade  to  diat  section  to  review  die  notation  and  naming 
conrentiona.  Ba^subsecdonfediides  a  deaGi4>6oa  of  die  module  transfonnation  rule  and 
die  sHpa  ini^ptying  dm  tnawfionnation.  Strict  spealdng.  dm  iraiii^bniiadoii  is  a  angle 
mp.  The  aunoiinifii^atepa  to  put  die  progranimo  fee  proper  fonn  is  die  transformation 
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Ihuidate 

The  tnunUtte  transfocmatioa  is  used  to  dumge  die  igsteseniation  of  a  datatype  and/or 
move  computation  along  the  data  paflis  of  a  progtam.  This  diange  in  rqaesentatinns 
is  ejqaessed  Ity  a  function  dutt  mips  from  the  original  representatioo  into  the  new  one. 
The  ttansfoimation  provides  a  medumiral  means  to  leinqdement  the  operations  of  dus 
datatype  on  die  ahenative  data  iqaeaentation.  The  meaning  of  the  abstract  datatype, 
hovfevei;  xemains  the  same.  This  ttansfiocmation  diffins  from  [7^  in  its  use  in  the 
integration  of  component^  shfft  is  used  to  opdmiee  within  a  single  conqmnent,  translate 
is  used  to  integrate  between  oonqxmrots.  Radierdian**synthesiang**  the  function  widun  a 
oonqnnent  diat  is  used  to  transfonn  die  original  program  into  a  more  efficient  one,  troitf/oiie 
uses  an  “analytic”  approach.  The  function  is  inoodnced  at  die  system  levri  between  two 
distinct  components  in  order  to  integrate  diem.  In  addition,  when  requires  an  inverse 

translation  function  that  is  difficult  to  define,  translate  could  be  used  as  an  alternative. 
^Ifidi  the  emphasis  on  integrating  datatypes,  dus  transfionnation  differs  firom  work  dcme 
by  Darlington  [17,  IQ  on  qmdiesizing  implementations  from  algebraic  specifications. 
Harrison  and  Khoahnevison  [4^  have  developed  an  automated  system  for  imptemeating 
datatypes  for  a  limited  language  where  diey  synthesize  the  inverse  mapping  function. 

In  order  to  tmderstand  the  franslatr  transformation,  we  examine  a  representative  selec- 
tion  of  operations  for  die  datatype,  that  produce  an  instance  of  die  type,  operate  on  die  type, 
and  reveal  some  hifonnatinn  about  the  type.  (Of  course  there  may  be  additional  paranmters 
besides  die  type  of  interest) 

Sipntan  omi «  sit 

typedtyps 

gen:dtyp« 

iKt :  dtyps  dtype 

0be:dtyp«-»v 


Oiven  a  spamting  function: 

Vie/ 

unapan :  Dtyp«'.<itype  -» Otype^Styp* 
unspanCDtypv'.AhaCa))  e*  otyp«>be(C^(a)) 

Rqdace: 

Streenwe  Otype :  DTTPl  ■  stracl 
type  dtyp*  «  Aba  af  a 

gan  •w  Aba(6) 
axKAbaCa))  Aba(B|A)) 
obacAba^)  as  otA 
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By: 


StradM  Dtyp*' :  DTYPE  >  rtracc 
lypc  dtyp*  ■  Abs  «f  o' 

urwptntten)  Dtypa^jan 

urwpanQHOCa))  otype^unspaiKa)) 
obt(^)  <s  Dtyp«4)tM0jn8pan(a)) 


Uiiag  the  notion  of  couBCtneii  idition  [46, 78],  we  can  ensure  dutt  unspan  is  a  valid 
abstraction  fimction.  An  abs&action  function  is  a  sajective  strong-hontomccphism  from 
the  rqpresentation,B,  to  tile  abstraction,  A.  We  coostnict  an  abstraction  fnncticxi, 

*dtyp«  •  ®<^yP«dtyp«  ®typ«dtyp«  O-*-.  *dtype  :«'-«)• 

Weinaposetiiereqnirenienttiuttitbesnrjective.  (A  reqnircoient  that  must  be  ensured  by  tiie 
software  designer.)  Theawecantiiowtiuabisasttongpartialhoniomofitiiism,consid^g 

csch  opCTmoT  is  twwi 

*dtyp«C*SBcK’®^  *  ^ext^^dtype  W) 

^ObS^  “  4Q|)g(A<ltyp«0d) 

In  our  transfonnation,  ndwie  we  treat  otyp«'  as  S  and  Dtype  as  A,  these  equations  are 
satinM  by  oonstruciai;  «  unspaa  A  similar  argument  holds  when  we  have  span 

(a  rqpresentation  fimction)  iMtPsd. 

Applytaig  the  transformatiaB.  lUs  ttansfinaation  is  tile  inqrartant  st^  in  a  series  of 
steps  tiiat  produce  tile  new  inqtlemeatation  of  tile  datatype.  The  data  rqpresentaiion  and 
the  impleineniation  of  the  openoions  cfaanpe,  but  the  meaning  of  the  dat^pe  remaiiis  the 
same.  The  faii^level  steps  of  die  transfonnation  are:  (1)  define  die  new  implementations 
as  data  tmsfonn  prooednrei^  (2)  imfiild  all  old  defiirfAwn;  (3)  **bridge*’  die  did  and  new 
representatioM;  and  (4)  fold  die  spanning  function.  FteliininarywofkwasdtmeinanEigD 
Seniiiag  on  Meeentialftognunining  by  Elliott  [24]. 

The  operations  are  defined  on  die  danaype  witii  rqnesentation  a.  For  exanqile,  obs 
ndoes  an  hucanoe  of  dm  Aaatype  as  an  ttgument,  reveals  the  undertying  data  rqxesentation 
of  die  bbstraaion  (rqnesenied  by  n)  and  returns  die  result  of  performing  some  operation 
on  h  fiepresenied  by  die  pattern 

Stractme  otsnpe  t  i>m*a  «  nrael 
dtype  «  Abe  sf  a 

gsn  Abs«7) 
rnmm)  ^  AbedCs)) 

M4bsd»  Od) 
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The  fimctiaii  span  mi^  die  given  datatype  rqvcsentatkm  into  die  new  lepiesnitaticm. 
From  now  on,  Dtype  .Abe  and  Dtype'.Abs  aie  abbreviated  as  Abe  and  Abe'. 

apafKAbaCa))  «=  Aba'(S(a)) 

The  new  impleiiientations  of  die  operations  are  defined  in  tenns  of  the  original  imple> 
mentations  on  a  (as  data  transform  procedures).  Stiicdy  speaking,  dus  is  die  translate 
transfocmatioo. 

SmKtanDtyptt' :  otype  astract 

dtypa  a  Aba  of  o' 

gan  c  apan(Dtvpe4)en) 
fi(Kapan(Aba(a)))  8pan(btype.6xt(A)) 
gbfi(apan(Aba(4i)))  ^  Dtypeob6(A) 

8pan(Abe(a))  <=  Abe'(S(a)) 

«id 

The  old  operation  dcfimtinnn  are  mechanically  "unfolded,”  diat  is,  the  names  of  the  (^lera- 
tions  are  rqdaoed  by  dieir  bodies. 

StraelBK  Dtypo' :  DTXPB  a  mrwt 
type  dtypo  a  Abe  of  o/ 

oan  uounCMaeCGH 
mCapan(Abo(a)))  ^  8pan(Abs(E(a))) 
gbKaparKAbaCa)))  o*  0(o) 

apan(Abo(a))  <=  Abe'(S(a)) 


The  span  fimction  on  die  rigjidumd  side  is  Hhewise  mechanically  "unfolded." 

SarwtanDtypo' :  DTXPE  aftracl 
typo  dtypo  a  Abe  of  o' 

gan  ^  Aba'(S(0)) 
nKipan(Aba(a)))  Aba^(S(E(a))) 
gbK8pan(Aba(a)))  ^  <m 

apan(Aba(a))  Aba'(S(tf)) 

tf  die  inverse  of  apan  oonld  be  obtained,  dien  deriving  new  implementations  of  the 
operations  is  earicg.  Sinqdy  miy  die  new  datsQfpe  into  die  old  representation,  perform 
dm  operMion,  and  dien  map  die  datatype  badt  into  die  new  rqnesentation.  Obtainingdie 
invermnny  not  be  practical  since  die  ^panning  fimction  may  not  always  be  one-ttHwe,  and, 
evaiifitwerB,diereinaybeiioeiaywiytoobtainiL  Radierdianconiingupwididieinverse 
espticidy,  it  te  aometiiiies  postible  to  use  syntactic  man^mlatioos  and  timidi&ations  to  in 
cfiect,  "invert*  the  ^panning  fimction.  TUsisaoooaqdidiedby  dmplifyingdieeiyiessums 
to  inatrihAe  new  ifpresentarionespressed  in  die  ppamiing  fiaaction.  TMs  is  y^ieie  insists 
about  the  domain  ftom  dm  developer  are  needed. 
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Smctvc  Otyptt' ;  OTYPE  «  Hract 
type  dtyp«  >  Abs  of  o' 

gen  <c=  Abe'CGO 
ffiSKspan(Abe(a)))  MxfWm 
gbi(S|Mn(Ab6(a)))  «=  <ym)) 

8pan(Ab6(a))  Ab6'(S(a)) 


Now  tibat  die  eiqitessioiis  in  die  operadcms  match  die  spanning  fonctuxi,  we  mechaniodly 
‘^ftdd*’ apen  <m  die  xighdiand  side. 

SinKtartOtype' :  dtype  sgtruct 
type  dtype  a  Abe  of  o' 
gen  <s  Abe'CGO 

fidCaparKAbeOi)))  ^  Abe'(E^(Rep'{span(Abs(fl))))) 
ggg(epan(Ab6(a)))  c  0'(Rop'(8pan(Ab8(fl)))) 

apan(Abe(a))  ^  Abe'CSCe)) 


Since  aU  innanoes  of  die  datatype  Sf^iear  in  die  context  of  8pan(Ab6(a))  which  is  die  new 
datatype,  it  is  xenamed. 

StractBoOtype' :  DTYPE  sstract 
type  dtype  a  Abe  of  o' 

gen  •«=  Abe'(G0 
SKAbe'(a))  <=  Abe'(E'(e)) 
gbB(Abe'(a))  ^  (/{a) 


New  inqdementations  of  die  operations  (lepiesaited  by  G',  E'^  and  GO  have  been  derived 
diat  operate  (» the  new  data  structure,  at',  direcdy. 


6^  Shift 

The  tnnafocmatkn  is  used  to  move  computadon  akng  die  data  padis  of  a  program  to 

increrae  die  efficiency  of  die  program  (eg.,  moving  computation  on  a  data  structure  from 
when  h  h  accessed  to  when  it  is  generated).  Hiis  may  change  the  data  representation  of 
a  Attatype  but  ffie  meaning  of  die  abstract  datatype  remains  die  same.  The  idea  of  a 
trmuAxmation  was  pieaemed  by  J0mng  and  Sdieriis  (49, 76]. 


tipedtype 

gsnidtype 

obas<reype-»v 
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Rqdaoe: 

StnMtaneDtyp* :  dtzpe  s  ^tract 
^pc  dtyp«  a  AbS  «f  dt 
gen  AbeCO 

gb8(Abe(a))  ^  Rep'CspanCAbeCa))) 
8pffiiCDtype.Ab6(a))  <=  Dtype'M)e(0(a)) 


By: 

StnMtareDtype' :  dtype  sHract 
^pc  dtyp«  a  Abe  of  a/ 

gen  <=  epan(Abe((^) 
ggfi(Abe(d))  Rep'(Abe(a)) 

epan(Dtype.Abe(<i))  ^  Dtype'.Abe(0(a)) 


5/4^  is  a  special  case  of  translate.  We  danonstrate  diis  by  using  translau  to  effect 
tbe  shift  fir«n  die  original  defimtion  of  die  tolerations  in  Dtype  to  the  new  definiticms  in 
Dtype'. 

gen  AbeCO 

gbttCAbeCa))  Rep'(8pan(Abe(<i))) 

J0ixing  and  Sdieriis  perfbnn  the  actual  shift  rqdacing  Abe  with  span  0  Abe,  and  span 
by  the  idendQr  fhncdoo.  loMcad,  we  introduce  a  stq>  for  defining  new  d^niticms  for  the 
operatioas  uring  die  translate  transfbroiation  to  define  altenudve  implementatitxis. 

gen  ^  apenCDtype.gen) 
giB(epan(Abe(a)))  <=  Dtypenbs(Abe(a)) 

Then  we  inedianica11y**unfidd”  die  definitions  ofdie  operations  00  die  ri^diand  side.  This 
puts  the  geneiaiar  in  the  desiiedftmnat,(f.e.,iq>]acing  Abe  span  oAbs).  In  die  observer 
ftmctioa,  die  datatype  is  ahea^  in  the  context  of  span  on  die  righdiand  side.  Thismatches 
the  occunence  00  die  kfdiand  ride  introduced  in  die  definition. 

gen  ap«KAbe(0) 
gta(epan(Abe(e)))  ^  Rep'cspancAbeCa))) 

Since  die  dataQfpe  in  obsqipears  only  in  die  contact  of  spat  it  is  letuorod.  ThisinodiK»s 
the  same  result  as  Scfaeriis  obtains  in  iqiladng  span  by  ^  identity  funcbon. 

gen  apan(Abe(0)) 
ghaCAbaCa))  <=  Rep'(Abe(a)) 

Wb  dien  shnfdify,  removing  the  alMtrBctkx?  boundary  in  obs. 

gen  ^  epanCAbeco)) 
gha(Ab0(e))  •(«  e 

life  now  have  the  timisforined  program  of  Dtype' where  span  hu  been  shifted  from  obs  to 
gsn.  A  similar  argniMid  holds  when  shiftfaig  ftom  gen  ID  obs. 
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Applying  the  tran^omatioii.  Hie  steps  for  transfonning  die  operatums  follow  for 
**advaacmg”  computation  from  tiie  observer  obs  to  the  graerator  gen.  It  is  also  posable 
to  **dday**  comiNitation  from  a  graerator  to  an  observer.  The  hi^-level  stqps  of  the 
transformation  are:  (1)  introduce  tiie  intended  new  boundary;  (2)  abstract  the  code  segment 
"between** tiieoldrqxresmitaticMiand  the  new  abstractkmintoanewfunctkm;  (3)acc(xnplish 
tiie  actual  shift;  and  (4)  simplify 
Wb  start  witii  the  original  d^niticm, 

Stroctorc  Dtype :  DTYPE  =■  stract 
tjpc  dtype  a  Aba  of  a 

gen  ^  Ab8(G) 
gi26(Ab6(a))  <=  (Ka) 


and  introduce  an  abstractiCTi  boundary  in  tiie  oteCTver  function. 

Strectuie  Dtype;  DTYPE  street 
tjpe  dtype  >  Aba  of  a 

gen  Abe(G) 
gbg(Aba(o))  <=  Rep'(Aba'(0(a))) 

cad 

The  next  step  is  to  advance  computatkm  by  mechanically  "folding**  the  new  abstraction 
into  a  span  function.  The  qianfunctkm  takes  the  original  abstract  datatype  and  produces  a 
new  abstraction. 

StractoK  Dtype :  dtype  sstract 
dtype  a  Abe  of  a 
gan  Aba(G) 

gtB(Aba(a))  ^  Rep'(8pan(Aba(a))) 
apan(Aba(a))  -0=  Aba'coco)) 


The  datatype  is  now  in  the  correct  format  to  tq^ly  the  transformatiem. 

Strartare  Dtype' :  DTYPE  a  itract 
typo  dtype  a  Abe  of 

gen  <=  8pan(Abe(G)) 
gtiKAbaCa))  or  a 

apan(Aba(o))  o=  Abe'fCXo)) 


ms  amq^fy  by  unfitiding  QMm  in  the  groeratoc. 
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Stractiire  Dtype' :  DTYPE  sitnict 
tjpc  dtype  B  Ab6  of  0 

gen  •«=  Ab6'(0(G)) 
gg5(Abs'(a))  <4=  a 

end 

We  see  that  shildng  under  these  conditicns  is  a  qtedal  case  of  the  more  general  translate 
data  transfonnatitn  technique,  udiere  die  new  graeiator  G'  is  0(G),  and  die  new  obsover 
<7  is  the  idmtity  function.  Since  the  span  hmction  is  uncovered  fnnn  the  observer  function, 
it  amply  dit^  out  as  we  duft  die  amputation  over  to  d»  genoator  function. 

623  Expose 

The  expose  transfonnatUMiis  used  to  reveal  die  underlying^pe  suacture.  This  has  the  effea 
of  moving  the  boundary  of  the  type  ^inward.”  The  AQiare  transfonnatiai  was  presented  by 
Sdieriisr?^. 

Given  spanning  functions: 

S :  r  -►  Ti  X  •  •  •  X  r, 

UtTiX  •••xTa-*T 
£/bS-‘ 

8pan(ptyp«.Ab6(<i))  Dtype'.Ab8(S(a)) 
unspenO}type'./^<i))  ^  VtypeM)6(U(a)) 

Replace: 

Structure  Dtype :  DTYPE  =  struct 
type  dtype  B  AbS  of  a 

gen  <=  Ab6(t/(G)) 

earn  <=  Abe(t/(E(S(R8p(«))))) 

6b6(a)  0(5(Rep(a))) 

end 


By: 


Structure  Dtype' :  DTYPE  sstruct 

^pc  dtype  B  Abe  of  a 

gen  «=  un8pan((Abei,...,Ab8,)(G)) 

exKe)  <=  un8pan((Ab6i,...,Ab6,)(E({Rep„...,Rep.)(span(c))))) 

obB(a)  «=  0({Rep, . Rep,)(8pan(a))) 

cud 

The  eagN»e  transfonnation rqilaces  all  instances  of  Abs  o  Gby  unspan  o  (Absi,...  ,Ab8M) 
and  all  instances  ofSo  Rep  by  (Repi,...,  Rep.)  o  span.  The  bodies  of  span  and  unspan 
are  pqxeaented  by  S  and  G. 
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can  be  diOQglit  of  as  a  **8trategy**  composed  of  moce  basic  steps.  Th^stqnare 
egqdabed  in  tenns  of  tbe  simider  transfonnaticm  stqn,  mtrodiicmg  an  abstroctioo 
and  folding  the  definition  for  span  or  unspan.  For  example,  starting  with  Abs  oU,  we 
introdnoe  an  abstraction  boundaiy  to  get  Abs  oi^o  (Repi,...,Rep«)  o  <AbSi,...,AbSii). 
But  the  first  three  composed  operadrxis  is  the  dt^nition  of  unspan,  so  folding  obtains, 
unspan  o  (Absi Abs«). 

Here  are  die  steps  for  rqtladng  all  instances  of  Abs  o  by  unspan  o  (Absi, ...  ,AbSji}: 


AbSoU 

Ab6oC/o{Repi . RepJo{Ab6i,...,Ab6«) 

urttpan  o  <AbSi , . . . ,  Ab^) 


Here  are  die  steps  for  replacing  all  instances  of  5  o  by  (Repi Rep.)  o  span: 


5oRep 

(RePi . RepJo(Ab8i,...,Abs,)oSoRep 

{Repi . Rep.}o8pan 


implying  the  transfomiatioii.  The  high-level  stqps  of  diis  transformadmi  are:  (1)  ma- 
nd^wlate  die  type  so  that  all  instances  of  Rep  ippear  in  die  context  5  o  Rep  and  all  instances 
of  Abs  i^ipear  in  die  context  Abs  o  U;  (2)  move  die  boundary  of  die  type  inward;  and  (3) 
excise  the  planning  functions. 

Wt  start  widi  die  original  definidon. 


Stractiire  Dtype :  DTYPE  «  street 
type  dtype  «  Abs  of  a 

gen  Ab6(G) 

SSKa)  ««=  Ab6CE(Rep(a))) 
gbs(o)  <=  0(Rep(a)) 


and  mampolate  die  representation  of  die  type  so  diat  all  instances  oi  Rep  qipear  in  die 
context  5  o  Rep  and  all  instances  of  Abs  appear  in  die  context  Abs  oC^.  This  is  deme  using 
simplification  stqis,  die  fold  tcansfonnadon,  and  insight  firom  die  software  develop^:. 


5 :  ot  -»  ai  X  •  •  •  X  o. 

U  m  Cl\  X  •••  X  Ota  Of 

Streciare  Dtype :  DTXPE  s  street 
type  dtype  •  Abs  of  o 

gsn  <0:  Abo(C/(G0) 

KKo)  Abo(C/(r(S(Rsp(a))))) 

Oafa)  *=  {/(Smepm) 
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The  daia^pe  is  now  in  Aeconectfonnat  to  qyly  die  opasetrangfonnatiop;  all  instances 
of  5  o  Rep  ate  iqdaced  by  (Repi Rep,)  o  span  and  all  instances  of  Abe  o  are  iqilaced 
by  unepan  o  (Abei,. .  •  >Abe,). 

StnMtare  Dtype :  DTXPE  s  uract 
^pe  dtype  a  Abe  of  a 

gen  ^  un8pan«Abei,...,Abeii>(CfO) 

tSSMfl)  <=  unspan({Abei,...,Abe.>(E'({Repi,...,Rep,>(span(a))))) 

QbfiCa)  <=  0'({Repi,...,Rep.>(span(a))) 

span(a)  -«=  {Abei,...,Abe»>CS(Rep(o))) 
unsparKa)  <=  Ab8(l^((Rep,....,Rep,>(a))) 

end 

This  has  die  effect  of  moving  die  boundary  of  die  type  ‘inward.”  In  Scheriis’  papex,  the 
next  step  is  to  use  the  release  transfonnadon  to  to  excise  the  span  and  unspan  portitms 
from  the  type.  Here,  we  instead  make  use  of  die  translate  nransfcnnatimi  to  derive  a  new 
imptementatiop  fordie  type,  revealing  die  underlying  data  structure,  die  tiqile  (oi  x. . .  xa,). 

Stractere  Dtype' :  DTYPE  s  mract 
typedtyp«a  AbSof(ai  x  ...  x 

gen  <=  apan(l>type.g6n) 

tSKo)  span03type.e]h(unspan(a))) 

obeidi  <=  Dtypen^uispan<a)) 

epanCa)  (Abei,...,Abe»){S{Rep(a))) 
unspanCo)  Abe(U((Rep„...,RepJ(a))) 


Next  we  mechanicaHy  “unfold”  the  old  operation  definitiems.  Tte  collection  of  abstraction 
functions,  (AbSi,...,Abs»),  is  qiplied  to  an  n-tuple  to  create  an  n-nqile  of  abstractions.  The 
collection  of  representation  functions  is  similariy  defined. 

Stracterc  Dtype' :  dtype  s  street 
typedtype«  Abeof(oi  x  ...  x 

gen  8pan(un8pan((Abei,...,Abe,>(G0)) 

ffiSKa)  <=  8pan(un8pan«Abei,...,Abe,)(E‘((Repi,...,RepJ(span(un8pan(a))))))) 
gpfiCa)  <=  0'((Rep„...,Rap,){8pan(un8pan(a)))) 

spaiKa)  ^  (Abei,...,Abe»>(S(Rep(o))) 
unsparKa)  Abe(l^((R6p„...,RepJ(a))) 


Simjdify,  diis  is  easy  since  span  and  un^ian  cancel  out 

Straclere  Dtype' :  DTYPE  «  rtract 
type  dtype  >  Abe  of  (ori  x ...  x  ohd 

gen  <=  <Abej,...,Abe»)(GO 

tSKa)  «=  {Abei,...,Abe>)CE'((Rep, . Rep,)(a))) 

gUKa)  «=  (y((Rep„...,Rep.)(o)) 


cad 
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&J2A  bicorptmLtt 

The  tnnsfionnaium  moves  an  extenial  (or  niodiite)  into  die  iniblic  part 

of  a  ^^pe,  or  a  public  fnnctioa  (or  module)  into  die  private  part  of  a  type.  Dedaradoiis 
in  die  inoocporated  stmctuie  must  be  evaluated  in  the  defining  environment  and  mane 
dashes  avoided  (of.  Standard  ML  semantics  of  die  **opea**  statemott).  There  must  be  no 
external  refemoestdien  moving  a  public  structure  into  die  private  part  of  the  type.  Hus 
ttantfonnadoo  is  used  for  qiecializing  modules  in  die  context  di^  qipear  in  by  moving 
external  functions  or  subcomponents  into  a  module.  Tlie  inco/porom  transfonnadon  was 
presented  by  Sdieriis  [76].  Similar  ideas  were  presoiiedl^  Wile  [91]  based  <mQear  [13]. 
Similar  qifdicatkms  to  modules  are  found  in  the  work  on  parameterization  in  OBJ  [33]  and 
in  Trace's  thesis  [8^  vriiereliieofponifie  is  an  instance  of  **removal  of  hocizcmtal  structure — 
inheritance  hierarchy  flattening.**  Any  module  diat  imports  anodier  module  can  be  reduced 
to  a  single  module  widi  die  same  functionality. 

Since  we  do  not  need  to  access  the  internal  structure  of  die  datatype,  we  use  a  general 
function  /  (vriiere{-}*  denotes  mnlti^  instances)  rather  dian  gen,  ext.  and  obs. 

Replace: 

SIgmaK  DTYPE  S  rig 
{/:0* 

cud 

Siractnc  Dtyptt :  DTXPE  X  ctract 

<=  by 


g(y*):j  <=  e 

By: 

Signtac  DTYPE  X  rig 
git 
ifity 

Structure  Dtype :  DTXPE  X  struct 

gOO  ^  € 

{/(»^)  <=  by 

Hus  is  a  one  st^  process,  so  unlike  die  other  transfocmatiras,  there  is  no  secticm  for 
qiplying  the  transformation. 

6XS  Release 

The  mfoase  transformation  moves  a  function  (or  module)  out  of  die  public  or  private  part  of 
a  type,  (provided  die  function  definition  does  not  ctmtain  any  references  to  the  abstraction 
fhnctkns  for  die  type).  Naming  conflicts  must  also  be  handled  (rg^  tty  iraaming).  The 
nrieosa  ttansfomurion  was  presoned  by  Sdmlis  [76]. 
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Rq)lace: 


SSpntm  DTYPE  «  dg 
gis 
{/:»}• 

tad 

Stractarc  Dtype :  DTYPB  s  ilract 
«(iO  <=  « 

in^)  ^  by 

cud 


By: 

Sigutaic  DTYPE  S  iig 
{/:*}• 

cad 

Stractm  Dtype :  DTXPE  s  stract 
{/(V")  <=  *}• 


g(v*)  :s  •«=  « 

Hus  is  a  one  stqp  process,  so  unlike  ibc  odier  transfonnations,  there  is  no  section  for 
iQq;>lying  the  transformatkn. 


63  Limitations  and  Benefits  of  the  Semantic  Model 

The  framework  for  die  module  transfotmatkm  system  described  in  diis  cluqiter  uses:  (1) 
an  algebraic  modd  to  oqilain  die  meaning  of  integradoo;  (2)  a  notion  of  a  correctness 
relation  to  eigdain  die  meaning  of  transformations  on  data  rgiiBseiitations;  and  (3)  theories 
to  ex]dain  die  meaning  of  transformations  on  abstract  interfaces.  The  modvation  for 
developing  a  framework  is  to  enhance  die  understanding  of  die  terms  used  informally,  to 
provide  structure  for  aiding  the  software  developer  in  using  dus  approach,  and  to  provide 
insight  into  automating  the  process.  Therelbee  the  emphasis  of  tins  duyter  has  been  on 
devdoping  enough  of  a  framework  to  muierstand  die  process  radier  dian  devdoping  all  die 

rt thf*  ffinantic  innAJ. 

The  dqpendency  of  using  Standard  ML  in  dus  framework  is  on  the  module  system, 
ladier  dian  on  die  language  itself.  Required  extensions  to  die  notation  to  ejquess  the 
transformation  process  include:  axioms  [7^,  views  [33],  eaqaession  procedures  [74],  and 
a  means  to  eiqxess  dternative  sdntioos.  Axioms  are  needed  to  onich  die  expressive 
power  of  Standard  ML  so  that  die  properties  of  die  aggregate  qiedfication  can  be  defined. 
Vkiws  cnaUe  the  software  dedgner  to  express  how  die  components  are  related  dnou^t 
consistengf  tdations.  Eiqptesdon  procedmos  provide  die  nocatkm  needed  to  eiqiress  the 
initial  definition  of  the  aggregate  tqxxi  vhiefa  module  transformation  roles  can  be  applied. 
Alienative  solutions  me  used  to  midntain  die  internal  consistmey  die  aggregate. 
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Ttebenefiti  of  flitoaeinMtticnwdd  come  from  its  simplicity  and  ifaeinri^itt  it  provides 
for  antnmatkin.  This  semantic  model  coold  be  enridied  in  a  number  of  wi^  Hie 
imitation  process  described  in  Section  6.1  implements  consisieocy  lelatioos  in  tenns  of 
translation  fimcrions.  Ifi^Mr-levei  abstractions  of  consistent  that  could  provide  a  better 
modellbrcKplaining  the  design  and  manipnlatinn  of  tnoAileinteroonnectioos ate  diacasaed 
in  Section  8.2.4.  AnootlineofdiemodntetimisfiDnnationnileswasprafvidedin  Section  6.2; 
tins  description  would  benefit  from  a  xidier  modd  for  imeifsoes,  exports,  imports,  and  a 
more  abstram  notion  of  eqoivalenoe  (see  Section  8.23).  Moro  details  on  how  die  module 
transformation  system  conqpares  to  idated  areas  of  work  are  discnsaed  in  CSiapter  7. 


Chapter  7 
Related  Work 


Section  7.1  begins  with  an  evahuttion  of  die  modnte  intofsoe  transfonnatioo  system  (re- 
fened  to  as  MTS  in  die  discussion  that  fdtows)  by  comparing  it  to  traditional  qiproadies 
in  soltwaie  engineering  to  detennhie  how  w^  die  t^proadi  addresses  die  problems  of 
iniegnidng  modnle  intcffaces  raised  in  die  b^inning  of  die  diesis  (Section  1J2).  Then,  die 
fidlowiitg  four  sections  evafaiaie  die  udli^  of  die  bfTS  tedmiques  by  comparing  dmn  to 
sevenl  related  areu  of  wosk:  bnOding  interns  from  software  components  (Section  7.2); 
defining  and  mana^g  rqnesentations  (Section  73);  data  design  and  refinement  (Sec¬ 
tion  7.4);  and  adqiting  interfmes  (Secdon  73).  Someoftfaerelaiedmediodshavesimilar 
modvaiionsorslunedaBclmiqDeswiiikodienareoomj^emeataryi^prooclies.  Daiatrans- 
fonnation  tedmiques  diat  dds  research  baOds  open  were  discussed  in  Section  22  and 
Section  63.  HnaPy  application  domains  for  diese  techniques  are  discussed  in  Section  7.6. 


7.1  IVaditioiial  Solutioiis  —  Revisited 

The  denwnstiated  MRTS  qtproach  addresses  the  probleins  of  integrating  module  interfaces 
(raised  earlier  in  Section  13)  in  die  subsections  dial  follow.  The  areas  of  related  woric  are 
groqied  according  to  diese  four  points  tritidi  cai^orize  trim  agreement  on  intedaces  in 
die  design  must  be  readied,  and  is  evaluated  widi  reflect  to:  scalabili^,  nqueariveness, 
qipropriaieness  of  represemations,  interface  agreement,  adaptabili^,  correctness,  perfor¬ 
mance,  and  automation.  AH  of  dieae  criteria  are  not  oonsidesed  in  eadi  of  die  sections  diat 
follow;  ladier,  die  importaitt  points  are  raised  as  appropriate. 

BnPdingSyatemeftnm  Software  Conpoocata.  Ratberdianreqniiingana/irionagrBe- 
ment  on  data  representations,  complea  datatypes  are  defined  as  a  collection  of  separate 
modniea  diat  are  systematically  merged  using  formal  mediods  to  derive  die  module  inter- 
Ckocs  flftd  dAcioot 

When  good  data  represemations  are  difificult  to  design,  eqiiedally  edien  diere  is  not  much 
eoqwrienoe  in  the  particular  qifdication  domain,  die  ^stem  derigner  can  define  a  complea 
datatype  as  a  collection  of  aeparaie  modnlra  These  modules  are  ystematically  merged 
wring  fanad  mediods.  The  mediods  also  facilitate  adaptation,  in  line  with  evohitiomgy 
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model!  of  devdopment,  since  the  process  of  adding  a  new  oonqxxieitt  is  similar  to  die 
process  of  merging  the  orignMd  components. 

In  Section  IX  siedficmion  Urngnages,  module  languages,  and  domain  languages  are 
evafamied  widiieqiect  to  eaquessiveoess  and  scalabili^  to  detennine  how  wdl  di^  support 
building  ystemsfiwmcoBciahins  of  nrodules  or  softi^coniiwna^ 

Dilllillg  ami  ^***"***-  tiy;i<WMtingiiq^maMtytinwf  tlmin£h 

mtennedbttelianslnto  functions,  new  module  interfmes  are  derived  diat  interact  dhecdy. 

TUs  has  beat  the  primary  focus  of  this  leseaidL  Translation  functions  provide  a 
notion  of  oonristency  among  die  oonqionents  and  transformations  are  applied  to  derive 
new  module  imerfroes  diat  interact  direcdy.  The  requirements  for  translatum  functions 
between  all  components  were  relaxed  to  allow  for  indh^connecrions  (via  an  intermediate 
conyonem)  and  connections  in  one  Erection  only. 

In  Section  73,  tedmiques  for  defining  and  managing  rqxeaentations  are  evaluated  with 
reflect  to  appropriateness  ofrqpresentatinns,  interface  agreement,  and  athqytalnli^. 


Duta  Dei^  and  Bejaemiiit  Radier  than  leaving  data  design  decisions  to  a  compikr 
sriiea  using  vcqr-lii^levd  languages,  die  software  designer  is  invtdved  in  defining  and 
organizing  module  interfaces. 

The  decision  was  made  to  involve  the  software  designer  by  giving  iiqiot  to  an  interactive 
systeminordertoalkiwforrichabatiactionsfarnseiHiefinedtypes.  Once  fonnalizedit  may 
be  possible  to  more  fogy  automate  die  qiproacfa;  this  has  been  left  to  future  reaearofa.  See, 
for  example,  an  antomadoo'based  software  development  paradigm  presented  by  Balzer  [4]. 
Harrison  and  Khoshnevison  have  an  automated  system  fiv  imidementing  datatypes; 
di^  use  an  qiproudi  similar  to  MIS  in  requhing  die  dmigner  to  qiecify  an  abstraction 
function  (essentially  a  translation  fimction),  but  use  a  restrictive  language  to  automatically 
syndiesiae  the  invetae  nuqiping  function  to  define  the  impkmentaiion.  Sinqilificationscan 
dwn  be  ipplied  to  derive  fimctions  diat  operate  on  the  new  data  stracture  direcdy. 

In  Section  7.4,  ftameworfcs  and  programming  environments  are  evaluated  with  respect 
tocorrectness,  performance,  and  automation,  todetenninehow  well  di^  support  die  process 
of  dataderign  and  refinement. 

Ad^^inglnlarfaocs.  Radierthanteqniringaprforfagteememooabstractintetfaoes,new 
types  may  be  defined  M  extensions  of  existing  ones  (eg.,  using  object-oriented  techniques 
sndh  as  inheritmoe)  and  new  module  interfaces  derived. 

The  contribtnion  in  ddsmea  is  in  developing  a  complementary  appeoadidiat  builds  on 
wing  wmAiIm  mmI  IQ  fd^t  abstruct  interfaces  •wtt  die«  appit^  derivations  to 

qxicisBie  the  impfcmentation  of  die  iidierited  module  in  the  context  rf  the  new  module. 
This  approach  has  numy  similarities  with  mediating  rrprrjrjitaikms  throu^  translation 
fanctions  and  can  nudoe  use  of  the  esperknoe  teamed  from  dds  eariier  effort 

hi  Sertton  75,  olject-orteated  techniques  and  transformation  syiiems  diat  siqiport 
evolution  are  evriuated  whfa  reqpect  to  interface  agreemem  and  adqxalnlity  by  means  of 
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7J2  Boildiiig  Systems  fh>m  Software  Components 

&i  diis  sectioo,  qiecificatkm  languages,  module  languages,  and  domain  languages  are 
evduaaed  widi  reqwa  to  esquessiveiiess  and  sralahitiiy,  to  determine  how  di^  siqiport 
boflding  systenu  from  softuw  components.  Evaluating  scalability  ndses  die  quesdoo, 
what  tedmiques  are  svailaMe  for  managing  larger  programs?  This  is  a  mqjor  souice  of 
modvrnioa  fbr  dus  invesdgttioa  of  transformations  and  module  interfaces.  Evahiadng 
CKpwssiveoess  laiaes  the  querfion,  to  s^bat  d^ree  are  die  coocqnual  propestiM  of  die 
pRiUem  reflected  in  the  tyntax  of  die  language?  Module  ficiUties  enable  mere  eiqilidt 
iqaeaentation  of  tystems  arefatoctnre  and,  daonib  infocmadoD  hiding,  enable  oooqxnaits 
to  be  designed  and  developed  sqiarately.  The  dialknge  is  to  develop  module  mechanisms 
and  famal  methods  approaches  diat  can  exploit  Tnodnlarity,  and  to  develop  formal  nwthods 
approaches  dm  sqiportagge^adon  and  int^radoD  of  conqionents  for  perfonnanoe. 

Even  dxn^  the  MTS  approadi  is  jfocused  at  die  system  design  level,  ^i^iidi  requites 
a  “prognunming  language**  in  onkr  to  numqndthe  data  iqneseniarions,  qiecification  Ian- 
guages  [9^  give  os  insights  into  die  structuring  of  huge  prognuns.  Larch  [38]  and  Z  [84] 
are  lepresMitadve  of  recent  devdopments  in  qiecification  languages  for  spedfying  huge 
programs. 

The  mih  is  die  basic  module  of  iqiecification  in  Lardt  A  trait  introduces  operators  and 
ipecifies  their  properties  (via  algehraicipecificariops).  Sometimes  die  operators  ooneqiond 
to  an  abstract  datatype;  snmerimestfaty  do  not  rince  it  nuty  be  desiraMe  to  qiedfy  properties 
that  do  not  quite  Goostitnte  a  type.  TVsits  can  be  combined  to  form  richer  traits,  and  a  library 
of  distract  interfhees  has  hero  constructed  to  aid  the  software  derigna:  CSonqionrots  in 
MTS,  like  traits,  describe  a  coflecdon  of  operadoos  that  may  not  consdtote  a  datatype. 

The  achemo  is  die  bade  module  of  ipecificadon  in  Z.  A  sdieina  introduces  domaiiis 
and  operaion  and  qiedfiesdieir  properties  (via  set  dieoiy).  Sdiemas  can  be  combined  in 
various  wqrs  to  build  laiger  prognuns  as  defined  by  die  schema  calculus.  For  example, 
Snftin  (891  laesZ  to  develop  a  dhpbgreditoa  Z  is  a  model-orieated  specification  language 
ndiere  one  defines  a  sysiem*s  bduwicr  by  constructing  a  modd  of  die  system  in  terms  of 
mtiiPimariffai  fficb  sf  Trying  to  develop  a  more  extendve 

editor  ftem  dds  definirinn  provided  die  tnotivation  for  introducing  conqiooents  dutt  are 
views  of  some  common  datatype  dace  it  is  difBcnlt  to  create  an  initid  model  of  the  buffer 
diet  lends  itself  to  specifying  all  of  die  various  operations.  Constramts  in  MTS,  like  Z 
iavathmia,  were  introdneed  to  describe  properties  the  datatype  that  are  not  restricted  to 

Ahhoudi  these  specification  languages  have  similar  goals  in  connecting  software  com- 
ponems,  diqr  are  deaci^tive.  They  nuty  describe  what  it  means  for  components  to  be 
rntrarelated  but  not  how  to  integrate  them.  This  tesis  is  adthessing  die  latter  problem  rod 
to  fxuaed  at  die  program  design  level  iriiere  module  interfaces  and  data  rqueseatations 
are  manipulated,  ^nceipecificaiionsdedwidi  a  hi^ierlBvd  of  abstraction,  it  to  neensary 
toroe  a  pregtammii^  language  in  uftich  distraci  interfaces  and  data  representations  can 
be  mg  man^pdated.  fToiuver,  diese  Imwjimijim  motivated 
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I¥om  die  nunqr  prognmnd^  laagnagBS,  Staiidard  ML  [61]  was  diosen  becBose  it  htt 
aa  el^aitt  modole  fiidd^  and  i  fiilfy  defined  semantics.  Iktaeova;  Extended  ML  [72] 
ad^  a  nieful  extension  to  die  language,  die  abiUQr  to  add  axioms,  and  gives  a  precise 
meaning  to  dwonnqioaing,  lefinii^  and  congpoang  programs.  This  gives  the  software 
designer  a  wkb»s»ectrum  langnage  to  represent  higiiep-level  tpecifications  that  can  be 
refined  to  an  implementabk  subset  Althougii  die  decision  was  made  to  base  die  notation 
on  Standard  ML,  die  tnmsftamatiootfyhniques  are  langnage  indq)cndent  and  can  be  applied 
to  odier  languages  with  modnles  such  as  Ada,  Qn,  and  bfodnla  3. 

Oognen  p3]  has  studied  die  issue  of  oonqmoent  integration  for  large-scale  systems, 
and  propoeei  a  module  imereoonecdon  language  0JL)  widi  a  program  methodol^  for 
wimpnrfiig  aoftware  components  diat  facilitates  rroae.  Gognen  introduces  dnee  smnan- 
dc  conoqns:  (1)  theories,  i^bidi,  like  Laidi  traits  and  die  MTS  definition  of  comptment 
^ledficadons,  asaodate  semantic  deaoriptkms  widi  software  ooaqwnems;  (2)  vi^,  t^iich 
describe  hnpiementation  altesnadves  for  software  interfaces;  and  (3)  horizontal  composi¬ 
tion,  wUdi  deactibes  structural  abenoadves  for  a  ^ven  levd  of  an  abstract  machine.  The 
MTS  notation  was  adqned  to  indnde  a  construct  for  views  to  enable  die  software  designer 
toeqxemhowdieoonqKmentsarerelateddiron^coosistencyidations.  ’nradirional  trans- 
fonaadon  tedmiques  deal  with  vertical  rtwnfnmticn,  whidi  refines  programs  to  a  lower 
levd  of  abatiact  machine,  The  MR  transformation  tedimqnes  for  integration  is  an  exam¬ 
ple  of  horiaQittaloonipoaition  that  is  necessary  for  structuring  large-scale  programs.  UL 
is  descriptive,  and  describes  tdiat  die  ahesnadves  are,  but  is  not  constructive,  ofiering  no 
guidance  in  impicancntiag  die  atonaiives.  The  tedmiques  developed  in  this  diesis  de¬ 
scribe  how  to  use  transfonnatioiu  to  sqipleaient  die  horizontal  composition  mediods  using 
a  oonsnuctive  qiproadi. 

"ftaca  develops  a  system  called  I JIJRANNA  [89]  based  on  UL  using  Ada  as  die  program¬ 
ming  language  extended  widi  ANNA  [56],  a  qiecification  language  for  Ada  that  allows  the 
insertion  of  amiotaiions.  Tracz  provides  a  model  of  module  conqwsitioo,  fully  d^nes  die 
oon^osition  mechanism  0n  LIL)  by  allowing  horizontal,  vertical,  and  groeric  instantiation 
in  mcxiole  eaqxessioos,  and  discosses  the  irlationship  between  die  various  types  of  module 
sttur.niring  IhisprovidesafinuaewotkfordesctibmgduBigestomochilesandmivgiveiii- 
aj^hmi  new  ttansformaihinsmid  the  structures  needed  for  automation.  Therequhenients 
for  oonqxiaing  modules  in  ULEANNA  makes  the  underlying  assumption  that  modules  diat 
dune  dam  have  the  aaase  dam  representations.  Ihe  MTS  mediods  provide  conqilementaty 
techiriquea  for  integrailng  muitl^iie  dam  representations. 

The  Draco  [62]  qrstem  aids  the  software  designer  in  constructing  software  systems 
firomrensahle  software parts,  llmaoftwaredesignernsesadbmaipihmgimgefordescribing 
programs  hi  encA  problem  area.  11m  objects  and  operations  in  a  domain  langnage  represent 
analyifi  jaftnamtion  about  a  proMem  domain  [261.  There  is  one  software  component  for 

ssehnplanaenaedbybeii^inodeledbydmoljecm  and  operations  of  odmr  domain  languiges. 
Bvanmaily,  dmdavelaphigprogmm  is  moddedhtaoonveatianalexBcntaUe  (programming) 
tangrom.  Ftapams  am  oonsBncmdftomte  objects  and  opermians  of  a  soitaUe  domain. 
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IttignafB;  iKiwevei;  M^pon  is  laddng  in  stractnimg  otitjects  and  operatioiis  into  dat^^ 
orolijectsOndieoljjecHxkotB^  For  example,  an  operatioii  and  an  otject  diat  it 
mtti^Nilaies  aie  lefined  sqpaniely  (sinoe  each  one  is  Rixeaenied  as  a  sefMcatB  coaqnoait); 
fufthennore,  tt>e  refinements  must  agree  oo&eQnderiyingrqHiBsentstion  of  Ac  object  The 
MTS  mefiiodology,  oo  die  odier  hand,  provides  a  systematic  means  to  readi  agreemrat  of 
die  reprosentarioo  of  die  otirject  and  to  derive  new  implementations  of  operatkms  defined 
ondieotgect 

Dnco  transftKmationsrqgesentoptimtMtinns  at  the  domain  language  levd;  Draco  re¬ 
finements  rnakeinqilcmentation  decisions.  lYadidorndtiansfcmnations  combine  die  Draco 
notions  of  transfonnadons  and  refinements.  The  MTS  rn^xxkdogy  similariy  makes  a  dis¬ 
tinction  between  using  transfonnatioos  within  and  between  domain  levds.  The  tediniqoes 
fior  integration,  in  effect,  stt^widun  the  same  domain.  Incootrast,ratherdiansoi]roe-to* 
sooroe  transformatians  wUdi  consist  of  a  lefdumd  side  diat  is  replaced  by  a  righdiand  side, 
MTS  uses  transfonnations  to  derive  and  manipolate  module  interfaces.  The  subsequent 
refinement  steps  make  choices  to  implement  die  program  in  a  mote  giedalized  domain. 
Refinement  in  Draco  is  an  interactive  process  vriiere  die  systems  designer  is  involved  in 
nuddng  decisions.  For  large  systems,  there  are  far  too  many  decisions  for  the  systems  de- 
signertomake.  Draco  provides  two  mechanisms  for  dealing  widi  tins  complexi^  domains 
and  tactics.  The  systems  designer  need  only  work  in  one  domain  at  a  time  iriuch  limits 
the  scope  of  what  to  dunk  about  Ihcticsfimit  the  number  of  decisions  dun  must  be  made. 
Even  nidi  diesemBdianisms.  as  systems  are  built  and  adapted,  a  Draco  system  may  become 
mcreasin^y  difBcnlt  to  mafaitrin.  The  software  devdoper  using  MTS  for  refinmnent  on 
dm  odier  hand,  uses  a  srnaU  set  of  well-defined  transformations  for  adjusting  interfaces  and 
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in  dtis  section,  trdimqnes  used  for  defining  and  managing  representations  are  evaluated 
with  reflect  to  die  criteria  for  appropriateness  of  renesentations,  interfsoe  agreen^t  and 
adaptahility.  Bvatuating  the  appropriateness  of  representations  raises  die  questkm,  how 
do  chosen  data  iqiresentations  reflect  die  requirements  of  each  componmit?  As  a  system 
evdves,  oonqKomises  are  ineviiabfy  made  to  data  rqneseatations  in  order  to  meet  diverse 
needc  often  expedient  soiotions  ate  developed  from  vduch  a  later  retreat  is  required. 
Bvahmting  interfile  agreement  raises  die  question,  when  most  agreement  on  interfra  in 
die  design  of  software  be  readied?  Delaying  design  decisions  vriien  a  priori  agreemmit 
cannot  be  reacheduMyrndBoftederign  proems  easier  initially  but  additional  wotkis  usually 
requited  to  int^tate  die  conqxmeats  later.  Evaluating  adaptahility  raises  the  question,  how 
ea^  is  it  to  inooqNxate  new  components  into  die  system? 

The  vfoiw  approach  of  Oarian  [29]  has  motivations  rimilar  to  die  MTS  ai^xoadi;  ladwr 
duB  having  todedde  in  advance  on  some  compromise rqpresentation,  sqmtate  components 
wiib  i^ipiopniic  iqpreiCBttWiont  m  ociudoci  ipo  ihbbt  imcgrupo.  lois  wicyws  sgreenicni 
OB  ittBHEfiiioos  to  occur  lotBf  ^bo  pcoocss*  Unlike  die  MTS  qiproadi,  however, 
meting  is  iBiiricted  to  a  smdl  number  of  fixed  datatypes,  dins  yielding  a  greater  degree  <rf 
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automation  at  tile  eaqpense  of  caqaesavenegs,  power,  and  flexibiliiy.  Ibcprogrammng-wUh 
WcNV  aiqproadi  of  the  Oandalf  gtoiq)  [39]  extnids  Gailan's  weak  to  sniqxxt  the  integratun 
ofjMPOgtaina(toob)thataoceaaandmaniiwilatea8hareddatarq»re8aitation.  Thedesaqition 
of  tile  riiaied  data  wpreaentation  is  factored  into  tile  individiialttKtis;  each  tool  (Mnea  its 
ofwn  view  of  die  data  structure  it  uses.  These  views  are  later  int^rated  by  describing 
how  faiformatioii  is  shared  between  tods  and  v^iat  invariants  must  be  maintained  betwero 
difitoent  views  of  the  same  data.  This  siqqports  die  merging  of  arbitrary  abstract  datatypes 
(that  are  connected  via  **oonq;iatibiIity  miqis*0>  but  is  tess  automatic  since  it  requires  all 
operations  to  be  lewiittm  by  hand  for  a  merged  type. 

The  MTS  tedutiques  for  deriving  module  interfaces  require  a  single  compatibility  miq) 
to  interconnect  any  two  conqiooents.  This  facilitates  die  design  levdl  of  integratum,  but 
requires  addMonal  work  at  the  implementation  levd  of  integration  t^iere  the  developer 
must  provide  some  guidanoe.  The  integration  of  die  components  is  resdved  at  compUe- 
ttme  under  MTS  but  at  runtime  under  Gandalf.  A  static  tqiproadi  permits  optimizations  to 
be  performed  as  wdl,  and  alleviates  die  additional  overiiead  required  to  handle  integration 
during  runtime.  It  is  important  to  keqi  in  mind  diat  the  MTS  techniques  were  derigned 
to  handle  a  slighdy  dififerent  problem  (udiiefa  permits  tins  static  iqiproach),  building  a 
datatype  from  a  collection  of  paeces  and  not  maintainmg  sqiarate  views  in  die  merged  type. 
However,  these  techniques  mity  provide  a  basis  for  formatizing  die  process  of  merging  in 
programming  with  views  (see  programndng  with  views  in  Sectimi  7.6  for  more  details). 

Whenever  a  dumge  is  made  to  a  component,  tins  may  affect  odier  compamts  that  in 
somewaydqmdoniL  The  tedmiqoes  for  manipulating  module  interfaces  isedate  dumge 
in  dhe  new  component  and  dien  propagaie  dia^  to  other  interdqiendeot  componrats 
through  the  process  of  integration.  Research  in  databases  has  siniilar  motivations  for 
introducing  and  propagating  change.  Balzer[^  provides  a  language  for  making  structural 
changes  to  die  description  of  a  knowledge  rqaesentation  system.  He  also  provides  tools 
for  nuqipii^  dioae  dianges  into  oorxeipooding  transformations  on  die  exis^  data.  The 
change  is  immediately  propagated  An  alternative  to  propagating  the  diange  immediately 
is  to  me  verdons  so  faat,  to  exanqiie,  types  of  d^ects  stored  in  a  database  can  be  dianged 
without  having  to  modify  existing  data  or  tools  [81]. 

The  ooexistenoe  of  old  and  new  data  and  tools  comes  at  die  cost  of  die  additional 
overhead  for  maimaiiiing  and  acoesdngmulti^  type  versions,  dumge  is  never  propagated. 
An  inlecmediaie  qiproadi  is  to  propagme  struen^  changes  only  when  data  is  actualfy 
accessed  by  a  system  configured  for  the  new  structures.  TfansformGmi  [85]  was  designed 
to  solve  tte  problems  of  grammar  evotution  for  stroctnre-orkmted  environments.  The 
impiementnrnudBesstroctmeddumgestodiegrammarofastructurB-oetoitedenvironnrent 
The  outymfitmTfansformGen  is  a  new  gnnnmar  together  widi  a  transformer,  which  takes 
insHnees  of  diiabiae  trees  built  under  die  old  grammar  and  automatically  converts  them  to 
tnetnaces  of  daabese  trees  diat  are  launder  die  new  grammat  In  MTS,  the  changes  are 
pcopi^aiBd  farnnediatrfy  however,  since  dumges  are  isolated  in  the  new  component,  the 
orlgbiii  tyinm  ^  effect,  an  eadkr  versfam)  is  still  availaUe. 


7.4.  DataDe^gnaadRilfinemaa 
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7 A  Data  Design  and  Refinement 

Id  this  section,  frameworiaanilpR^tanuiiiiigeaviioimaeiits  are  evaluated  widiiespe^ 
crilexia  to  oooectness,  periSonnance,  and  antoniatioQ,  to  detennine  how  wdl  they  support 
tile  process  of  data  design  and  refinement  Evaluating  conectness  raises  die  questtot  how 
can  hi|^  assurance  of  cooectness  be  provided  to  larger  systems,  or,  latiier,  toaqiects 
of  bdiavior  of  larger  systems?  Evaluating  peitomance  raises  tiie  question,  i^iat  dances 
are  availaMe  to  tiie  d^gner  to  improving  die  efifidency  of  a  program?  These  mig^t 
indude  techniques  tiuttaftot  the  frequency  of  execution  of  parts  <rf  die  program  and  how 
readily  information  is  made  available.  Evalnating  automation  raises  die  question,  what 
dements  (tf  die  process  of  prodncmg  efteient  programs  from  higfa-levd  programs  can  be 
mechanized?  The  naain  emphasis  here  should  be  on  achieving  productive  interactimis  of 
automated  systems  widi  developers  and  maintainers. 

There  are  a  number  dt  formtU  fhaneworks  to  developing  larger-scale  programs  by 
transfr)nningliigh*levd  ^lecifications  into  executable  code.  Like  die  MTS  approadt  diey 
sedt  to  extend  transfrnnatioo  techniques  to  larger-scale  systems,  and  similariy  involve  die 
software  designer  in  die  design  of  data  representations  (usually  in  order  to  avoid  limiting 
the  expressiveness  of  the  specification  language).  The  developm  of  OP  [5],  to  example, 
advocate  using  dgebraic  qiedfications  as  die  starting  pdnt  to  a  top-down  medmd  of 
program  devdopment  The  developers  of  Extended  ML  r73]  and  VDM  [7]  use  formal 
verification  to  invent  new  implementations  and  prove  diem  correct  The  MTS  qiproach 
differs  from  these  in  its  support  to  the  integratkm  of  sqiatatecompoomits.  This  gives  the 
designer  the  flexibility  to  delay  agreemmdon,  as  wdl  as  adqit,  die  interfaces  of  a  (module) 
system. 

The  Programmer’s  ^iptentioe  f7(]!l  provides  assistance  in  die  implementation,  design, 
and  requirements  jriiaaes  of  die  langramming  task.  A  formal  rqnesentation  to  programs 
and  programming  concepts  is  provided  die  Plan  Cdculus.  A  jdan  is  a  generalized 
representation  of  nprograatmd  is  rqireseDted  as  a  gnqjdi  structure  consisting  of  boxes  and 
arrows.  The  boxes  denote  operations  and  tests;  die  arrows  denote  cmtnd  and  data  flow. 
The  rgaosentation  has  a  graphical  notation  and  a  formal  smnantics  used  to  reascming. 
Relationships  between  plans  (eg.,  ipecification  and  inqilementation)  is  rqnesented  by  an 
overhQT.  An  gveiigy  defines  a  nuqiping  from  die  stt  of  instances  of  the  implementation  plan 
to  a  set  of  instances  of  die  ^pedficatioiL  ft  is  a  generalization  of  the  abstraction  fun^cm 
in  dm  idistract  datatype  methodology,  like  overlay’s,  MTS  translation  functkns  rqnesent 
rrlatinmhipt,  but  relatiniMliips  between  components  widun  a  gtven  levd  of  abstraction, 
radier  dam  telationriiips  between  different  levels  of  abstractiotL 

The  Design  Apprentice  (a  subsystem  of  die  Rcogrammer’s  An»oatioe)  is  detigned 
ndiere:  (1)  a  tadc  is  cjqiressed  in  a  dedarative  (^ledfication-like)  iiqmt  language;  (2)  tte 
qrstem  provides  detection  and  caqdanation  of  errors  made  by  the  programmer;  (complete¬ 
ness  and  coniisiBncy);  and  (3)  die  system  antomaticalty  sele^  reasonable  implementation 
dwiees.  htfiormation  is  embottied  in  **diche^(oambiiuuions  of  program  elemmits).  Per- 
hips  the  mediods  developed  in  this  tfaesii  could  be  used  to  build  cliches  in  the  first  place. 
Then  the  MTS  methodology  could  use  cliches  as  a  mediod  to  rrase. 
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The  MTS  m^x)d(dogy  allows  the  designer  to  choose  die  data  rqnesentaticHi  and  to 
customize  it  in  die  context  that  it  iqipears  in,  unlike  odier  methods  where  representadcxis 
and  opdmizatkms  are  chosoi  from  a  predefiiMd  set  ^TL  [79]  is  an  muunple  of  a  very- 
hj^kvel  language  based  on  set-theoretic  syntax  and  sonantics.  For  the  most  part,  the 
SETL  usor  is  not  involved  in  choosing  data  representations.  Instead,  diey  are  automatically 
chosen  by  a  compiler  for  each  abstract  object,  based  cm  a  catalog  of  c^tinuzadons.  The 
optimizer  does  not  make  any  significant  change  to  die  algoridunic  fonn  of  the  program,  it 
being  more  conoerned  widi  the  data  iqxeaentation  that  siqiports  the  qiedfied  algorithm. 
Wkte-iyeetniin  langnageg  meh  m  itefiiMi  [82]  give  die  software  develc^  more  ccmtiol  by 
providing  an  interactive  oivitonment  where  die  devekqiier  can  q^ly  cptimizatimis  based 
on  die  usage  and  omtext  of  die  data.  The  optimizations  are  drawn  from  a  set  of  supplied 
rules  and  templates.  OBJ  [34]  can  be  considered  an  mcecntable  specification  language.  It 
provides  a  notation  for  structuring  algebraic  qiedfications  into  hieratchies  of  parameterized 
modules  [28].  Radia  than  focusing  on  data  represmitatioos,  die  OBJ  system  implements  an 
equational  rewriting  systenL 

The  MTS  also  have  important  differences  with  the  transformation-based 

qiproach  of  Ifisgen  [45],  which  seeks  to  optimize  user-defined  d  ata^pes  automatically  by 
using  predefined  ^pe-apedfic  transformation  rules.  The  inogrammer  writes  pre-conditicms 
and  post-conditions  as  well  as  transformations  for  each  operation.  Ifisgmi's  mechanism  is 
well  suited  to  die  development  of  customized  ^pes  for  use  in  a  very-high-level  language 
system.  The  type-qiedfic  optimizations  provided  by  a  type  designer  can  be  applied  auto¬ 
matically  by  a  compiki;  but  the  type  designer  is  reqxmsible  for  their  correctness.  Instead 
Of  anticqmting  die  collection  of  trimsfonnations  needed  in  advance,  the  software  devdqper 
using  MTS  has  a  small  ocrilection  of  well-defined  transformations  to  use  to  customize  the 
datatype  in  die  context  diat  it  qipcars  iiL 

In  program  synOie^  by  Manna  and  Waldinger  [57]  programs  are  extracted  frmn  a 
constructive-style  proof.  The  proof  serves  as  a  high-tevel  language.  Recent  developments 
in  dus  ityproadi  to  manipulating  proofs  include  inogram  development  tiirou^  proof  trans- 
formation  [68].  While  diis  provides  a  scduticm  to  die  problem  of  designing  die  initial 
program,  there  is  still  die  need  for  a  complementary  process  diat  optimizes  die  extracted 
program  by  manipulating  die  data  rqnesentations  and  die  structure  of  die  interfroes.  Thms- 
formation  tedunques  could  provide  dns  ciqiability  [1]. 

7  J  Adapting  Interfaces 

In  this  section,  obgect-orknted  tedutiques  and  transformation  systems  that  support  evolutimi 
are  evaluaied  with  reqiect  to  the  criteria  for  adaptability  by  means  of  modifying  existing 
interfaces.  Evaluating  interface  agreemoit  raises  die  question,  vrimi  must  agreement  on 
interfaces  in  the  design  of  software  be  reached?  Delaying  design  decisions  whmi  npriori 
agreenumt  cannot  be  readied  nuty  make  die  design  process  easier  initially  but  additicmal 
work  is  imnlly  required  to  int^rate  die  oonqiooaits  later.  Evaluating  adaptability  raises 
die  question,  how  easy  is  it  to  modify  existing  interfaces  and  incorporate  new  cmnponents 
into  the  tysiem? 


76.  ApplUuxtions  for  the  Modide  Transformation  System 
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Thiditional  (dyect-oriented  techniques  [87]  raable  the  developmoit  of  customized  ab¬ 
stract  inteifaoes  based  tm  existing  types,  but  widt  rqnesmtations  and  implanentadons 
shared  among  die  variants  (eg^  dnou^  inheritance).  That  is,  in  the  object-orirated  worid, 
a  "qiedalizfid  type”  of  one  or  more  existing  ^pes  may  have  a  specialized  abstract  interface, 
but  die  underlying  implementation  will  fttndamratally  be  determined  (throu^  inheritance) 
die  existing  type  implementations.  This  can  limit  die  ^dmicy  of  die  implonaitadon 
and  has  led  some  languages  to  allow  violadons  in  abstractum  boundaries  by  permitting 
access  to  dwrqnesentation  of  die  ancestors  of  an  inherited  object  [83].  A  more  controlled 
iqtptoach  is  die  “ftiwids”  declaration  in  C-H- [86]  where  classes  have  qpecial  access  to  other 
classes  diat  are  declared  friends.  Tlieresearchptesentedindiisthesis,however,maypro- 
vide  a  means  to  obtain  truly  specialized  implementadmis  for  die  qiecialized  types  by  means 
of  program  transfonnadons.  The  NfTS  techniques  provide  optimization  and  integration 
of  multiple  rqnesoitations  to  complement  the  object-oriented  approach,  which  supports 
flexible  integraticm  and  rahancement  but  requires  compatible  interfaces. 

Griswold’s  worit  [36]  on  program  restructuring  as  an  aid  to  software  maintenance 
uses  a  transfocmatiraial  qiproach  to  address  a  difreient  problem.  He  introduces  a  set  of 
automatable  transformations  to  manipulate  the  structure  oi  a  system  for  supporting  evolution 
dnoujh  manqiulation  of  program  structure.  These  transformations  are  ^lied  locally  m 
effect  a  syntactic  change;  the  system  may  make  non-local  changes  to  presave  data  flow 
dqiendence  and  ctmtrol  flow  dependence.  Griswold’s  work  focuses  oa  die  transformation 
of  die  syntactic  amstructs  of  a  block-structured  language,  whoeas  MTS  is  focused  at  the 
module  ’^veL 


7.6  Applications  for  the  Module  lY'ansformation  System 

Domains  where  this  qiproach  is  useful  include:  the  developmoit  and  evolutimi  of  proto¬ 
types;  the  reuse  of  software  modules  in  libraries;  programming  with  views;  heterogeneous 
tystnns;  and  type  managonent  for  persistent  objects. 

Devdopment  and  Evolution  ct  Prototypes.  In  die  develt^ent  and  evolutitm  of  pro¬ 
totypes,  a  ptincqial  objective  is  achieving  functionality  in  die  easiest  possible  way.  For  a 
complex  type  in  a  system  (i.e.,  distract  datatype  interface)  widi  many  qperati(»is  associated 
widi  it,  it  migfrt  be  difficult  to  design  a  single  rquesentation  diat  is  suitable  for  prototyping 
and  exploratory  developmoit  of  all  of  die  various  qperations  of  the  abstract  datatype.  In 
such  cases,  it  might  be  eaaer  to  design  a  collecticm  of  sqparate  rqnesentatirms  that  w^  for 
vaiioosnibsetsofdiefrillsetofqperatums.  Individual  operaticMis  could  thus  be  sqiatately 
prototyped  uringqjiptoiviaterepresentatirais.  The  problem  dim  is  to  assemble  the  various 
qpetatioos  and  conflicting  rqnesentations  into  a  sin^  type  diat  can  be  merged  into  a  larga 
prototype  system  and  possUily  transformed  into  a  hi^  performance  implementaticm. 

Rensable  ’Jbrwies  of  Software  Modules.  These  transformatimi  technique  may  also 
enhance  die  ability  to  create  and  retain  software  objects  for  reuse  [SO]  (eg.,  the  Larch  [38] 
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fibnny  of  abstract  interfaces).  One  factor  that  makes  reuse  hard  to  realize  is  diat  mul- 
t^  developers  of  system  comptmmits  widi  shared  abstract  interfaces  will  evolve  data 
represoitiaioas  that  conflict  Ihe  ccmflicts  are  ncx  due  to  a  failure  to  settle  interfaces  in 
advance,  but  due  to  tedmical  needs  that  motivates  dioices  by  aq>arate  implementars  {eg., 
die  context  in  which  an  qieration  is  used,  fiequency  of  use,  q;>aoe/time  tradeoffs  desired, 
or  flexibility/effidency  tradeoffs  desired).  Beomse  of  dus  conflict  components  cannot  be 
shared  unless  additional  compmioits  are  implemented  that  translate  rqaesentatiaas.  The 
cost  of  dds  translation  is  usually  too  high  except  iit  a  prototype. 

This  research  eiqdores  reuse  tfaroogb  customization  [23, 76],  and  provides  a  framework 
for  the  adiytation  of  datatypes  and  the  manipulati(»<rfinterrdated  modules.  An  instance  of 
dns  framework  is  a  network  of  generalized  and  specialized  versions  of  abstract  data  types 
where  dw  MTS  technique  builds  and  maintains  die  network. 

Piropaaniniiis  with  l^ews  The  Janus  systmn  [3^  supports  the  merging  abstract 
datatypes.  The  techniqnes  developed  in  ^  diesis  may  he^i  formalize  this  process  of 
merging  t^iere  transformations  **compile**  views  into  a  canonical  form  and  specialize  diem. 
Janus  provides  four  lands  of  storage  modds:  disjoint,  derived,  duned,  and  "anything  goes.** 

In  die  disjoint  storage  modd  die  fields  of  a  merged  class  are  die  disjoint  union  of  the 
Adds  of  die  component  classes.  This  corresponds  in  smne  way  to  die  process  of  "merging** 
where  die  Adds  of  a  data  amregate  are  the  ooss  product  df  die  Adds  of  the  compmumts. 
As  widi  dutjoint  union,  all  die  fields  from  each  origmd  compmient  rqqiear  sqiarately  on 
the  merged  aggregate.  The  diflEeiCTce  being  that  sqiarate  views  are  not  maintained  in  the 
aggregate.  Eadi  component  contributes  to  die  new  single  aggregate.  It  could  be  possible 
to  implement  views  on  top  of  this. 

In  die  derived  storage  modd  die  fields  from  one  ctf  die  origind  classes  are  not  stored 
mtyUcidy.  Instead  dieir  values  ate  dynamicdly  calculated  when  needed.  This  cotreqxmds 
to  die  process  of  "translating**  wbat  die  fields  ffom  one  component  are  not  stored  but 
calculated  from  odier  fields  in  die  aggregate.  This  could  be  done  dynamically  via  a 
translation  fnnctkm,  or  statically  by  deriving  new  implementadons  the  compcment  based 
on  a  new  rqnesentationdurt  is  stored  in  the  data  aggregate. 

In  die  shared  storage  modd  two  fields  from  die  origind  classes  are  stored  as  a  single 
fidd  in  die  merged  dass.  This  is  a  qiedd  case  tff  "translating**  where  die  fields  from  one 
conqxxirat  are  not  stored  but  calculated  from  die  (dier  fields  m  die  aggregate.  Since  die 
data  is  ideridcal,  dini  die  operadoiis  can  be  oidmized  to  manqmlate  die  shared  data  direcdy. 

In  die  "attydung  goes**  storage  modd  the  merged  class  contains  fields  diat  have  no 
dhectcorreqiondencewitfafiddsfitomany  of  die  origind  dasses.  Thiscorreqxmdstodie 
specialization  stqp  of  deriving  an  efiBcient  implemaitatioo  from  die  prototype.  It  is  also 
possible  that  a  more  generalized  imidementadoa  could  be  derived  [21].  There  is  in  fact 
a  oorxeqiondenoe  which  is  recorded  in  die  derivation  in  terms  of  die  design  decisions  and 
transformation  siqis  takmi  to  produce  die  new  data  aggregate. 


Hetnrogeneoos  Systons.  The  draft  tqxirt  on  a  Common  Prototyping  Systnn  [3]identi- 
fiesrequireiiients  for  a  language  and  system  that  supports  prototyping  as  a  first  step  towards 
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bidldiiig  heteapogeneons  systems.  The  report  identifies  die  need  for  **multi-language  in- 
teroperalnlily*’  Htoe  firagmonts  of  existing  code  are  "composed**  in  a  prototype.  One 
mbproblem  involves  ccmverting  data  items  from  one  rqgesentarion  used  in  one  Imguage  to 
therepresentatimiusedintfaeotiiei:  Hayes  and  Schlichting  [44]  have  devekqaed  a  solution 
to  dus  data  representatum  problem  in  mnltq>aradigm  programming  for  a  fixed  set  of  stan¬ 
dard  datatypes.  Peiiuq>s  data  aggregatitm  can  provide  a  solution  for  us(u:-defined  datatypes 
as  welL 

*l>pcMani^anaitfor  Peraisteit  Objects.  Ifow  does  one  propagate  the  effects  of  chang¬ 
ing  a  type  tt>  instances  in  a  persistent  store?  A  key  subinoblem  is  iqpdating  the  library  of 
persistent  otyects  [IQ.  One  sdutuxi  is  to  use  a  view-based  model,  and  the  MTS  iqiptoach 
cmild  systematically  develop  die  merged  type  rqnesmitatimis.  Anodier  solution  is  to  em¬ 
ulate  the  new  behavior,  and  die  MTS  approach  could  aid  d»  process  of  finding  a  type 
lepresentatimi  that  could  support  the  functionality  of  onulation. 
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Chapter  8 
Conclusions 


The  aganizatkm  of  imetfaoes  among  system  canponents  is  a  key  task  in  tbc  ctmstruction 
and  management  of  latger-scale  sofhx^  systems.  Datatypes  and  modules  that  interact 
must  agree  not  only  on  the  abstract  interfaces,  but  also  oa  data  lepresentaticxis  if 
implementadons  dure  data.  As  a  sc^tware  system  evolves,  the  need  to  adapt  existing 
inteifaoes  can  arise.  Thus,  dus  problmn  of  integraticm  persists  for  as  kmg  as  die  system  is 
maintained. 

This  diesis  has  dunonstraied  diat  program  transformations  (semantics-based  program 
manipulation)  provide  systematic  siqiportfor  integrating  general-purpose  software  modules 
into  efficient  tystems.  This  qiproach  also  provides  stqipoct  for  active  and  perfective 
maintenance.  Complex  type  definitions  initially  ocmsist  ai  a  number  of  componoits  dut 
are  composed  via  translation  functions  and  module  extensions.  The  initial  interfaces 
are  dien  integrated,  resulting  in  complex  composite  interfaces,  by  using  data  aggregation 
transformations. 

8.1  Contribations 

This  thesis  has  dnee  major  contributuns:  (1)  New  transformaticm  tediniques  for  data 
aggregation  that  eiuUe  tte  qiplication  of  transformation  techniques  to  the  develqiment 
and  ada|»atiao  of  laiger-scale  systems.  (2)  A  hand-conducted  study  of  the  derivation  of 
a  diqdity  editor  dut  illustrates  a  pioof-of-coooq;it  for  die  methodol^.  (3)  A  framework 
for  describing  data  transformation  techniques  dut  enhances  die  understanding  of  die  terms 
used  informally,  provides  structure  to  aid  die  software  designer  in  using  the  approach  ami 
is  an  important  stqi  towards  automating  the  system. 

Larger-Scale  Systems.  The  first  contribution,  new  transformatUm  tediniques  for  data 
aggregation,  enisles  die  qiplication  of  transformation  teduuques  to  the  develofunmit  and 
atfaquation  of  larger-scale  tystems.  Hgure  8.1  is  an  abstract  view  of  diis  process  for 
coosttiicting  systems  using  die  module  interface  transformation  system,  and  cortesptmds 
to  die  enumerated  nept  Hated  below.  The  process  starts  widi  die  design  of  die  top-levd 
aggregate  ^lecification  (st^  1).  The  software  designer  Driio  wishes  to  design  a  complex 
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system  is  able  to  decompose  die  problem  into  compoomits  diat  best  model  that  portkn 
of  the  problem.  The  components  may  be  obtained  from  a  library  of  software  ass^  of 
standard  imeifittes  or  prototyped  by  the  designer  using  a  data  representation  diat  most 
closed  models  the  stdifHoUem.  Consistwicy  relations  eaaMirii  ooneyondences  among 
die  data  representations.  This  a^egate  e^dfication  is  used  in  die  imegnid(m  phase 
to  produce  an  agregate  defimtion  (step  2).  (Xitaining  die  aggr^ate  definition  from  die 
aggregate  qiedficadon  is  a  medumical  process  once  oon^adbili^  mqis  (ududi  leqiect  die 
consistency  idttions)  are  provided.  Hie  aggr^ate  definition  is  in  a  format  tqiooud^  data 
translarions  can  be  peribnned  to  obtain  an  executable  prototype  (step  3).  Then  additional 
transfrsrmations  such  as  ssgxare,  incoiponire,  release,  mid  can  be  perfcrnred  to  ofnimizB 

die  prototype  into  an  effidentfiigdementot&mCsiqi  4).  Later  on  die  sctftware  designer  may 
wish  m  mtroduce  additknal  functionality  in  die  adcqir  phase. 

The  msential  stqM  for  impkmeating  datatypes  or  modules  by  components: 

1.  Structun  (compose)  tte  system  unng  tnodules.  List  die  operations  diat  constitute 
the  retpnrements  for  some  tystem.  Define  the  component  implementatiCTis.  each  of 
s^iidi  mqdements  some  sul^  of  die  interfisce.  Collectively,  aU  of  die  components 
intpiementdieentiremieifree.  Use  module  extensinns  to  aday  die  abstract  interfaces. 
BwahHA  mxy  data  invariances  among  die  components  by  defining  functions  that 
translate  from  one  component  rqarpjcjitatioo  into  another  to  establish  die  consistency 
of  dm  collection  of  data  rqxesentations. 

2.  inUfrme^compoiiiemtade^^datat!^ormoduU.Oaocmnsio*'taagtSa^ 
representation  die  product  of  ^conqioncatrqprejentations.  Eadh  operation  defined 
in  a  component  induces  a  coereyonding  operation  on  dbe  composite  datatype  or 
module.  Eadi  operation  definitioo  is  pot  into  a  format  amenable  to  transformation. 

3.  Derive  the  MstexecmdtkpnMtypeaftim  datatype  or  tnodule.  Since  die  definitkais 
are  data  transform  proceAires,  d^  is  done  by  qiptying  transfiannations.  The  ex¬ 
pression  piooednres  are  transformed  into  funciioaaldefiiiitioiis.  When  adqiting  the 
system,  it  mity  be  possiUe  to  reuse  some  of  die  information  from  die  derivation  of 
die  im^mdon  of  die  ori^nal  system. 

4.  Derive  an  effidem  implementation  by  translatUm.  Uncover  an  effident  represen- 
tation  by  eKminating  rnmnorsiary  redundancy  and  qiecialiring  data  in  die  context 
dutt  it  ippears  in.  Derive  efficirot  inqilementatioos  of  the  operations  on  die  new 


Using  these  techniques  suggests  a  paradigm  for  datatype  implementation  by  **oompo- 
nents.**  Sometimes  it  is  dHBcult  to  design  types  or  anticipate  future  needs.  Instead  of 
introdiicing  a  type  mdanriripating  all  necessary  operators,  die  operations  are  des^ned  as 
we  dsoover  the  need  for  diem  in  die  prognm  using  the  datatype.  The  rqieaentations  are 
00  dio  Hds  mggeits  a  p— *«ngwi  of  system 

fanplHiieniaiion  by  modules  udieie  we  use  transformation  techniques  to  get  better  perfor- 
nuDce  fasn  sfanpty  leusiiv  code.  The  module  transformation  syflem  provides  a  wity  to 
num^mhoe  die  modules  and  to  dumge  die  cohesiveness  and  die  ooiqilmgs  of  die  modi^ 
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These  ptndigiiu  provide  benefits  to  icaliiigpriinarily  at  die  design  level  Cooqdexity 
is  managed  dnooifi  abstraction,  modnlariatioo,  and  stq>>wise  tiansfarmatkw.  The  focus 
of  die  softtvaie  designer  is  on  the  design  domain.  These  design  decisions  are  translated 

inln  rhangM  riimnghmit  thft  Ht  d>e  ™*eg»*don  ^r^^"*^»***d**»  "d 

opfimizediesysienL  The  formal  man^wlarions  at  dnsle^  are  generally  carried  out  widiin 
local  coroeats.  However,  in  onkr  to  claim  diat  dds  m^md  tnity  scales,  thoi  assistance 
is  needed  at  die  integration  ingdcmentatkai  level  in  carrying  out  an  of  the  stqis.  Most  of 
diese  ate  aaediaiiical  siqisdiat  could  be  performed  with  automated  support 

More  eagperience  using  the  tedmiqnes  mi^  lead  to  interesting  olgect-orimited  appU- 
cadons.  Object-oriented  prograrniniiigsiqiportsflexitdeml^tation  and  eiihanoeiiient  but 
requites  compadbie  imerfooes.  These  techniques  provide  opdmixadon  and  integration  of 
mnlt^  representations  so  die  two  techniqiies  ate  comptanentary.  This  could  be  done 
initially  widdn  die  notation  based  on  Standard  ML,  sinoe  objects  widi  state  can  be  defined 
usii^  ML  functors,  and  a  dni|de  inheritance  nmehanism  is  supported. 

nroof-uf-Coaeept  The  second  contribudoo,  a  hand-conducted  snxty  of  the  derivadon 
of  a  di^lay  afii^  iUnstrsies  a  proof-of-concqit  for  die  niediodology.  This  diesis  shows 
die  hard  problems  of  module  interfooe  int^rsdon  diat  occur  in  software  devdopment  and 
introdncesamethodologydiatcompienieiits  or  enhances  existing  methods  for  solving  diem. 
The  advantages  of  uing  dds  methodology  inclnde  die  ability  to  delay  dedsioos,  to  have 
the  system  infer  some  of  the  information  for  the  inqdeaiawadnn  from  the  design,  and  to 
reuse  die  insights  and  transformation  stqis  fiom  previous  devdopments. 

In  order  to  demonstrate  the  techniques  for  integtsting  modnle  imerfooes  by  progtam- 
transformadons,  a  shupie  interactive  display-editor  was  developed.  First  a  text  buffer  was 
iinpieniented  and  then  adtfitional  functionality  was  introduced  to  demonstrate  how  the  text 
buffer  is  adapted.  The  decision  for  die  data  repiesentsdon  of  die  buffer  was  delayed  until 
after  the  httegradon  process.  The  components  were  sinq>^  connected  (via  oompadbili^ 
nuys);  die  mediodology  provided  a  systematic  means  to  infer  the  otfaer  connectioni  when 
they  were  needed.  Daring  adaptation,  a  sin|ie  connection  between  die  new  cooqionent 
and  dhe  existing  qraiem  was  needed;  once  die  new  representation  wu  integrated  widi  die 
connecting  component  from  die  existing  system,  the  imegradon  with  the  rest  of  die  g)rstem 
can  make  use  of  existing  inri^its  and  traiafoeinationatqis.  By  going  dnongfi  die  exerdae 
of  constrncdng  a  buffer  from  conyonems  and  dienaddhig  additional  components  to  adiqpt 
the  buffer,  a  lesson  was  learned  diet  components  can  implement  parts  of  a  datatype  ai^ 
foe  foe  int^radon  of  die  parts  an  aggregate 


Next  die  foens  of  foe  exanqde  changed  to  foe  module  level  and  foe  buffer  was  used  as 
apsrtofahngBrdispiay-etfooraysiBaL  Tim  lessons  learned  inchided  how  tcansforinadon 
teclmkpies  can  be  applied  to  hierardtically  stmetnred  module  systems,  where  modules  are 
defined  in  terms  of  other  modules,  Thebafedataqrpefoatliaslmprevioiulydevdopedis 
reused  and  custOBsinBd  la  die  context  of  a  huger  intcrscdvefoiplsy-etBtor.  Triuttformsdons 
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While  nsiiig  the  module  inmfiKe  traiudbnnatiao  qfstem,  die  focus  of  die  software 
desiguer  is  on  die  design  domain  and  away  from  the  qifdicatioo  of  die  tedinique  (i^iidi 
is  the  traditional  tiansfognadoo  igproacfa).  At  die  design  jdiaae,  die  system  is  composed 
fiom  copqionentt  ;;;idi  stndgjhtforward  implementations.  During  the  integnoion  process, 
die  inaights  deal  widi  reasoning  about  die  domains  in  ^riddi  die  components  are  modeled. 

Antnmaring  die  tedmiqne  is  an  important  stqi  to  accomidish  nmct,  so  diat  more  expe¬ 
rience  in  dus  and  other  domams  can  provide  additional  information  about  die  qiplicability 
of  die  ledmiques  and  die  costs  associated  widi  using  them. 

FtrameiPOriK.  The  dded  oontribudon,  a  firsneworic  for  describing  data  transformadon 
tedudqnes,  enhances  the  understanding  of  the  terms  used  informally,  provides  structure  to 
aid  die  software  designer  in  using  the  approach  and  is  an  important  step  towards  autoniating 
the  system.  A  notation  based  on  Standard  ML  [39]  modules  is  used  to  refsesmit  die 
components  of  a  system.  In  addition  to  rqxesenting  datatype  definitions  and  modules,  the 
notadon  needs  to  also  eiqpiess  die  other  structures  in  die  transformadon  process.  Required 
extensions  to  the  notation  to  cjqness  die  transformation  process  include:  axioms  [72], 
views  [3^,  eityresrion  procedures  [741,  and  a  means  to  express  aheroadve  solutkms. 
Axaoms  are  needed  to  enridi  die  eaqiessive  power  of  Standard  ML  so  that  die  properties  of 
the  aggregate  qwdficatian  can  be  defined.  Views  enable  die  software  designer  to  mqsess 
how  die  components  are  related  diroo^  consistency  relations.  Eityression  procedures 
provide  the  notation  needed  to  express  die  initial  definition  of  die  aggregate  upon  which 
module  transformarionnles  can  be  apiriied.  Ahernadvcsolntioos  are  used  to  maintain  the 

iirtwmal  aggT^We, 

As  progiCM  is  made  in  explaining  die  techniques  in  terms  of  a  finmework,  it  may  be 
possible  to  treat  die  derivation  process  as  an  obrject  diat  can  be  formally  manipulated  and 
to  cqxnredwinsigldsfttim  the  software  designer.  This  increases  the  potential  for  reusing 
the  previous  derivations  hi  hnegrating  the  existing  tystem,  when  adqiting  the  system  by 
adiBog  a  new  component.  TUswasdoneinformallyindieeditordetiviuioiwbyreosmgdata 
tnnrfarm  procedure  definitions,  die  strnctnre  of  tte  transformation  stqps,  and  some  of  die 
hm^its  provided  by  die  software  developer.  See  Baxter  [til  and  Cheaduun  [IS]  for  formal 
lyprouches.  One  way  to  manipnlatp  or  optimire  the  process  would  be  to  qiply  die  technigocs 
to  the  conqiatihility  nugis,  for  exantyie,  conqule  a  lertgtfay  sequence  of  compatibility  miyis 
into  a  shtyie  compatibility  nuy  or  produce  die  transitive  closnre  to  get  connections  between 
all  of  die  components  stnting  widi  a  ooOection  of  oornponoits  diat  are  simply  connected, 
b  abo  nuty  be  possflde  to  generate  die  inverse  compatibility  maps  as  well  (udiro  diey 
exist).  Another  oprimixation  is  to  synthesiae  q^ecialiaed  compatibility  nuqis  between  the 
OOll^OOBIIIl  IMI  COwiprllC  ID6  mfgttgUt  ITODI  WC  OOinpinDHHy  uU^it  aOIOIIf  CoC  OngUUU 

componems  and  die  refinement  step  (iriiich  can  be  viewed  u  a  translathw  fimmion  from 
die  aggregate  prototype  to  the  aggrqpnr  implementation).  Of  course,  dififering  strategies 
could  be  devised  to  obtain  diese  new  compatibility  miys.  Rather  dum  obtaining  diem  all  at 

only  when  needed,  or 

The  tnmslarinn  ftmetion  need  only  respect  the  comisiency  relation,  by  ttanshuing  one 
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aolitwaie  devdoper  piovidet  to  enaMe  die  ooostrnctioo  of  alieniative  inqileiiiai- 

tatioM  of  a  component  Theae  insigjto,  in  eflGMt  area  database  of  infonnation  about  die 
properties  of  die  dam  mddieirintetdqtcndenciet.  Periiqis  diese  imeid^endencies  could 
be  fonnalized  as  partial  tranriatkw  functions  (with  infofination  obtained  from  insi^st^ 
Mid  die  properties  of  operations)  duu  cqNure  die  insipbts  provided  die  software  devd- 
opec.  As  die  database  of  infonnatioo  is  built  ty,  the  translatinn  fimetion  may  eveMually 
o^Kure  all  of  die  intesdqiendencies  among  die  data  to  fully  implement  die  consisiMicy 
idation.  This  provides  a  meebanism  for  reusing  die  insights  from  die  software  designer, 
and  in  some  cases,  constructing  the  inverse  translation  function,  which  gready  simplifies 
die  transfonnation  process. 

The  prototype  and  implementation  stages  may  not  have  to  be  two  distinct  steps.  Oden 
a  great  deal  of  work  is  done  in  die  prototype  stage  only  to  be  discarded  later  on.  It  may  be 
possible  to  use  a  fonn  of  filter  promotion  to  prune  out  die  derivations  diat  are  unlikely  to  be 
firnitfnl,  or,  to  use  a  form  of  huty  derivation,  or  derivation  on  demand  so  that  die  stdtware 
developer  only  ejqiands  enouph  of  die  derivation  diat  is  needed. 


8^  'Diniiiig  the  Method  Into  a  Software  Reality 

A  formally-besed  mediodcdogy  has  been  devised  for  systematically  integrating  software 
components,  dnouph  die  mediation  of  abstract  interfaces  and  nndedying  data  r^resenta- 
dons.  This  provides  for  die  ability  to  dday  or  revise  design  decisions  v^ien  it  is  difScult  to 
teach  an  gprforf  agreement  on  interfaces  or  data  rqaesentations,  Aproof-of-conceptfor 
dus  mediodcdogy  has  been  demonstrated  by  the  derivation  of  an  interactive  display-editot: 
However,  ddsmediod  is  not  yet  a  software  reality:  (1)  Coonections  need  to  be  es^lished 
widi  software  process  mod^  The  mediodcdogy  of  die  module  transformation  tystem 
could  h^  reduce  die  risk  that  a  software  tystem  does  not  conform  widi  die  actual  ne^  by 
providing  earikr  validation  widun  a  softwmprooenmodd.  The  software  process  model 
could  provide  more  guidance  to  die  software  designer  constructing  software  systnns  using 
dre  module  transformation  system.  (2)  Automation  is  an  inqwrtantstq;)  in  malting  progress 
toward  turning  die  coooqx  into  an  engineering  mediod.  (3)  A  more  formal  model  of  die 
ttansformation  system  would  aid  in  the  eaqilanation  and  automation  of  die  techniques.  (4) 
Int^ration  is  low-level;  notions  of  consistency  at  a  higher  levd  of  abstraction  dian  trans- 
lation  fonctions  mity  provide  better  models  for  explaining  die  design  and  manqnilatum  of 

tntfjmnnniifftinwf 


8.2.1  Softwire  Process  Modeb 

Connections  need  to  be  establiriied  widi  software  process  models.  The  mediodcriogy  of 
die  modide  transformation  system  could  h^  reduce  the  risk  that  a  software  Systran  does 
not  confownwidi  die  actual  need,  by  providing  cariier  validation  widun  a  softirere  process 
modd.  The  software  process  model  could  provide  more  guidance  to  the  software  deagner 
constructing  aonware  systems  usmg  me  moguie  transtormaooo  system. 


B2.  litming  the  Method  into  a  Software  Reality 
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Rednciiig  the  Rfak  of  SystanNonoonformaiioe  with  the  Actnal  Need.  Process  models 
have  been  developed  to  organize  die  stages  software  developmmiL  The  waterfall  model 
is  die  basis  for  most  software  development  in  govenimmit  and  industry.  Develoimient 
is  divided  into  stages  (eg.,  lequiranents  analysis,  qpecification,  coding,  testing.  There 
is  feedhadr  between  successive  stages  and  a  form  of  prototyping  duou^  the  building 
of  an  initial  prototype  in  parallel  widi  requirements  analysis.  While  die  waterfall  model 
mity  work  well  for  problems  diat  have  a  well  d^ned  domain,  dds  traditional  qjproach  to 
developing  software  (Figure  8.2)  -  lequiremaits,  analysis,  qiecificatkm,  validadtm  -  does 
not  always  yield  die  desired  result  because  often  all  die  requiremaits  are  not  known  in 
advance,  but  require  some  eagwimentatian.  This  is  true  t^ietfaer  die  implementadcm  is 
designed  squrately  and  dien  verified  or  is  derived  using  formal  techniques.  This  entails 
high  risk  because  formalized  requirements  are  not  validated  until  very  late. 

In  any  software  development  diere  are  two  important  conoqnnal  points.  The  point 
of  making  a  decision  (eg.,  design  decisions,  data  structure  coromitmmits)  and  die  point 
of  learning  die  consequences  (U.,  die  validation  of  die  earikr  dedaon).  The  interval  in 
between  is  a  measure  of  die  risk  involved.  The  longer  die  interval,  die  greater  the  risk  diat 
die  iintial  decision  may  not  be  die  correct  one  t^iich  will  affect  subsequent  decisions  diat  are 
based  on  die  initial  decision.  The  way  to  reduce  risk  is  to  try  to  bring  die  two  ptnntsdoser 
togedter;  either  by  delaying  decisions  (eg.,  abstracting  fimction)  or  by  advancing  validadon 
(eg.,  building  prototypes  or  reusing  validated  componoits).  There  are  ccmstraints  on  how 
mndi  die  points  can  be  shiffed.  Delaying  dedsioos  cannot  be  dtme  indefinitely  and  too 
mudiddity  may  produce  over  generalized  results  that  are  ineffidmit  likewise  advancing 
validation  is  feasible  only  in  the  context  of  givoaresouroes. 

The  qnralmodd  [8)  creates  a  risk-driven  approach  to  die  software  process.  Itacccxn- 
modam  the  good  features  of  other  software  nodds  (eg.,  die  waterfall,  evoluticmary,  and 
tramform  models)  uhOeavoidiiq;  many  of  didrdifSculties.  Software  process  modds  can 
be  impiDved  Ity  devdoping  moie  teppott  fee  the  incrementd  creatkin  and  adiqMation  oi 
tystems  (Figure  83)  tningfaemd  methods  (ci.inferentidprogramniing  [77, 51]).  Require- 
ments  am  be  med  to  produce  prototypes  t^provkie  feedback  for  early  and  incmnoitd 
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Hgnre  83:  Evcdutiooary  Ihmsfonnaiioo 


validatkm  and  hence  lednoe  risk.  Derivatuxis  are  tri-diiectional  —  a  prototype  can  be 
refined  towards  an  impleoientatioo  cr  “generalized”  towards  a  more  formal  specification 
(see  work  by  Dietnen  and  Scheriis  [23]  for  some  dKWigjhts  on  gmieralization).  Such  a 
mediod  woi^  support  an  increment^,  evolutionary  q)proach  to  prototyping  and  systems 
devek>|mient  that  is  bodiadi^Kable  and  driven  by  ri^requhonents.  It  would  also  focus  tm 
the  iSgm>ise  attainment  of  appropriate  levdstrfabstractioo.  function,  and  scale  for  complex 
inierfi^  and  complex  tystems. 

This  thesis  reaeaidi  incoqKxates  tedmiques  firom  inferential  programming  widi  a  nar> 
rower  focus  on  prototyping  and  a  wider  focus  on  scaling  and  adapting  interfeces.  The 
research  assembtea  a  set  of  techniques  that  siq[>ports:  (1)  creation  oi  prototypes  diat  in- 
vdveoom]fiex  typed  oigects;  (2)  adqnation  of  these  prototypes,  including  restructuring  of 
type  signatures  and  additioo  of  new  rqacsentations  for  newly  delineated  operatiCTi  subsets; 

(3)  evdutian  of  prototypes  into  efficient  irnffimnentations,  brace  reuse  of  prototype 
filaments  dnou^  aggr^ation  and  customizatkxL 

Stin,  diere  are  numerous  issues  to  be  addressed  for  such  a  model  What  structure  will 
derivatioos  take?  How  are  derivatioos  manqmlated?  \ifill  a  new  high  level  language  be 
required?  Before  some  of  these  brood  issues  can  be  addressed,  it  is  useful  to  have  smne 
practical  mqterience  with  some  exanqdes.  This  diesis  contributes  by  mqiloring  a  “vertical 
slice”  of  the  issues  that  is  narrow  and  deq>,  in  order  to  mqxMe  some  of  die  research  issues 
and  focus  on  die  overall  structure,  ft  examines  die  relationships  among  requiranrats, 
prototypes,  and  inqdementations.  Therefore,  some  od  hoc  decisions  have  been  made 
regarffing  doivadon  design  structure  and  language,  to  provide  a  basb  for  more  detailed 
future  research  in  eadi  of  these  areas  of  die  modd. 


GdManee  in  Conslmcliiv  Systems  Uifeig  this  Approndi.  Gonnections  codd  also  be 
establiriied  widi  software  process  models  to  provide  more  guidanoe  in  constructing  soft¬ 
ware  tysteare  uaii^  die  module  transfosmadon  system.  Software  process  modds  diat 
nfport  prototyph^  and  evotudon,  sudl  u  the  ^nral  Modd  [8],  could  provide  guidance  in 
evafoadnf  foe  choices  made  avaUitlde  by  die  qiproodi  devdoped  in  this  thesis. 
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The  **slioe**of  die  derivathm  model  (Hgure  8.3)  tfaatis  devdopedin  dds  diesis  provides 
an  ovenll  methoddogy  to  guide  die  software  designer  in  the  design  and  develt^ent 
process  (Hgure  8.1),  a^  criteria  such  as  the  cost  ci  integration  and  implementaticm  are 
available  to  evaluate  the  consequences  of  making  certain  decisions  (see  C3uqtter  S). 

The  methodology  provides  a  structure  siqiporting  devetopmauL  It  also  records  die 
design  dedrions  made  during  die  integration  process  triiidi  are  usefiil  for  later  modificatimi, 
adiytadoo,  and  maintenance.  Still,  an  "t^licadon  theory**  is  missing,  airi  must  bellied 
mcterndly  by  die  software  designer.  The  tq^lkadon  die^  is  not  part  of  die  mediodology 
because  all  of  the  information  is  not  available  in  die  modute  systmn  itself.  Many  decisions 
are  based  on  the  environment  in  which  die  system  is  to  be  used  and  die  non-fiinctional 
requiranents  of  die  user.  Such  informatum  is  available  from  the  software  process  model 
Widun  such  a  process  model,  this  methoddogy  provides  a  specific  capability  where  the 
software  process  model  provides  advice  on  how  to  proceed  [93]. 

8,2,2  Automation 

Automation  is  an  important  step  in  making  progress  toward  turning  the  omcept  into  an 
engineering  mediod.  Qupter  S  provided  an  interpretation  of  d»  results  of  die  editor 
derivation.  The  benefits  diese  techniques  offer  occur  primarily  at  die  (fesign  level  In 
order  to  make  this  mediod  accessible,  assistance  is  needed  at  die  implemoitation  level  in 
canying  out  aU  of  die  stqis.  Many  of  these  are  mechanical  stqis  that  can  be  performed 
with  automated  siqporL 

An  initial  prorject  would  demonstrate  the  implementadon  of  a  program  derivation  system 
for  a  shxqpk  functional  language  (such  as  a  subset  of  Standard  ML)  siq^lemented  with 
eaqacssion  procedures.  This  program  (ferivadon  system  could  be  constructed  using  the 
EigoSiqiport  System  [52].  Automated  assistance  is  available  in  die  form  of  tools  that  store 
and  diqday  die  programs  and  ipply  die  selected  transformations.  As  more  informatimi 
is  learned  about  dus  process,  more  of  die  information  provided  1^  die  designer  may  be 
shifted  to  die  tools,  for  example,  by  tmilding  strategies  out  of  transformaticm  stq»  and 
implonmiting  thmn  as  metaprograms.  Here  are  die  relevant  comptments  for  an  initial 
project: 

Syntax  Facility.  Given  a  BNF-like  grammar  for  the  language,  die  syntax  facility  [22] 
produces  a  parser,  lexer,  and  niqiarser  for  translating  die  program  into  an  absttact  syntax 
tree,  manipnlating  the  abstract  syntax  of  die  program,  and  di^laying  the  program  on  a 
screen. 


Aurityria  FMffity.  Given  an  attribute  grammar  based  on  the  abstract  syntax  of  the  lan¬ 
guage,  die  analy^  freility  [64]  produces  an  analyrsr  to  compute  die  anribute  values  of  a 
program.  Thisisoaefulfordoingdata&}wanalysis[63],pfovi^gdietruisfocmati(mswith 
additkinal  information  about  die  context  (eg.,  the  incorporau  and  release  transformadcms 
need  information  about  name  conflicts  and  variable  r^erroces). 
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btcraction Facility.  Tl»intBractumfacility[27]usestlieuiiparsertodisplaydieprogram 
on  a  screen,  and  allows  the  user  tt>  and  manipulate  the  abstract  syntax  of  the 

program.  This  is  essradal  for  an  interactive  approach  where  tiie  designer  needs  to  point  at 
the  pn^ram  to  offer  hints.  Other  views  of  the  process  are  also  provided,  such  as  displaying 
tibe  derivation  as  a  tree  structure. 

The  derivation  is  not  necessarily  a  linear  progression.  Some  fcnn  of  hyper-text  system 
would  be  us^iil  for  navigating  thrcmgli  die  design  choices.  MellowCardinovides  a  simple 
mechanism  to  navigate  throu^  textual  infonnaticni,  which  is  useful  for  recording  the 
design.  There  is  a  need  to  extend  tiiis  mechanism  to  navigate  through  programs,  pitmfs, 
and  derivations  as  structures  in  their  own  right 

Lambda  Prolog.  Some  form  of  meta-language  is  necessary  to  represent  the  derivation 
process,  for  example,  to  repress  tiie  transfotmatirms.  Lambda  prolog  [69]  is  (me  poten¬ 
tial  meta-language  and  has  been  used  to  express  transformations  [40,  41].  The  use  of 
hi^ierKxder  abstract  syntax,  where  tiie  bindings  of  variables  are  explicitly  represented,  is  a 
useful  feature  for  eiqiressing  and  manipulating  the  scqies  of  variables,  and  for  expressing 
abstraction  and  qiplicaticm  transformatirxis. 

Pferabtent  objects.  The  changes  to  die  program  and  die  recorded  derivation  (including 
design  decisions)  need  to  be  stored  for  later  retrievaL  A  persistent  object  database  [71]  pro- 
vides  storage  for  diese  objects  that  persist  beyond  die  lifetime  of  any  particular  qiplication 
of  the  derivation  program. 

8,23  Formal  Models 

A  more  formal  model  of  die  transformatuxi  systnn  would  aid  in  the  eiqilanation  and 
automation  of  die  module  transformation  tediniques.  A  firameworit  for  the  derivation 
syteem  was  presented  in  ChiQiter  6.  Using  a  tiieory  of  data  abstraction  and  the  correctness 
of  modular  programming  (eg.,  Schoett  [78])  could  aid  in  die  eiqilanatirm  and  autranatimi 
of  die  tecfamqoes. 

Tb  assert  diat  die  module  transformation  rules  preserves  die  meaning  of  the  datatype, 
we  must  have  a  framework  in  t^uch  to  define  die  meaning  of  datatypes  and  operations  that 
can  be  performed  on  diem.  One  way  to  think  about  the  meaning  of  programs  is  to  use 
Natural  Semantics  as  used  in  the  definition  of  Standard  ML.  For  example,  B  P  ^  M, 
where,  “against  die  backgroandff,  die  {dnase  P  evaluates  to  the  meaning  AT  [61].  When 
a  transformation  transforms  a  program  P  into  a  i»ogram  P',  it  is  possible  to  check  if  they 
evaluate  to  the  same  meaning  widun  die  same  environmmiL  See  [47]  for  a  discussion  of 
odier  frameworks. 

Schoett  presents  a  theoretical  explanation  for  the  correctness  of  programs  obtained  from 
mo&ilar  programming  using  data  abstraetkm.  He  develops  a  die^  of  “cells”  which  are 
used  to  rqpreseitt  die  imerfaoesof  modules,  and  are  rquesentedin  “design gtiqihs.”  He  uses 
die  modd  to  give  a  formal  definition  of  decomposition  and  compositirm,  and  (ff  refinmnmit 
in  terms  of  a  correctness  rdation  baaed  on  behavioral  equivalence. 
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Composed  Cell  S' 


Global  Spedficadon  S 
Deoonqnsition 


C^omposidofl 

Contctness  relation 
Cell  s=>  Spec 

:  ^  ^ 

Cell  se-  Spec 

Figure  8.4:  Gxnposability  of  Refinemmits 


A  key  dieocmn  is  the  amposdbUity  of  refinements  (see  Figure  8.4).  Infonnally,  the 
theorem  states:  Let  the  collection  of  spedficati(ms»  ilf,  be  a  decomposition  of  the  ^obal 
qiedficatuxi,  5.  LetlhecoUectioDofimp]mnentadcxis,ilf',beac(»iponentwisere/hieiitenr 
of  M.  Then,  S',  die  aunposition  of  ilf',  is  a  lefinemoit  of  S.  Informally,  the  pftoof  of  the 
dieorem  of  the  composi^bility  of  refinements  c(»sists  of  showing:  (1)  The  unirm  of  the 
signatures  of  M',  is  a  syntactic  refinemmit  of  die  signature  of  S.  (2)  Whenever  A  is  a  base 
(i.e.,  a  background  or  envixonment)  for  5  them  A  is  a  base  for  S',  ibest  exists  a  result  of  S' 
on  A,  and  every  result  of  S' <m  A  is  result  (tf  S  (m  A. 

Schoett’s  theory  could  be  extended  to  allow  hierarchical  crmpositioDS  and  decomposi¬ 
tions  in  order  to  sli^  die  correctness  of  transfonnatums  on  abstract  interfaces  by  moving 
abstractimi  boundaries,  such  as  die  incorporate  and  release  transformadons  defii^  in  diis 
thesis.  This  could  be  accomplished  by  defining  what  it  means  to  incorporate  or  release 
cells  in  the  cell  theory.  The  iiqiut  and  ouqiut  of  the  program  transformadmi  can  dien  be 
translated  into  a  family  of  cells.  To  show  dm  transformatkm  is  correct  requires  a  proof  that 
die  family  of  cells  produced  by  the  program  transformadrm  satisfies  the  d^nitirm  of  what 
it  means  to  incorporate  or  release  cells  in  the  cell  theory.  Schoett’s  correctness  relation 
can  be  used  to  show  the  correctness  of  transformadmis  oa  data  representations,  such  as  the 
translate^  sh^  and  expose  transformadons  defined  in  diis  diesis.  This  is  acctnnplished  by 
demonstrating  diat  die  span  and  unspan  fimcdons  presave  certain  properties  tt>  qualify  as 
a  proper  correctness  relation. 

Are  there  a  complete  set  of  module  traiisformationrules;  are  d»  ones  covoed  sufficient? 
There  are  undoubtedly  more  which  will  be  uncovered  as  additional  eiqietience  in  using  the 
mediodology  is  q^li^  to  other  dmnains.  The  (mes  necessary  for  the  integradmi  process 
have  been  covered  It  would  be  interesting  to  look  at  transforming  design  grqihs  and  see 
what  module  transfontuukxis  or  classes  of  transformadons  they  suggest 


8^4  Integration  is  Low-Level 

Integration  is  low-level;  notions  of  consistoicy  at  a  higher  level  of  absttacticm  than  trans¬ 
lation  functions  may  provide  better  modeb  for  eiqilaining  die  design  and  manipulatUm  of 
module  interconnections.  In  Quqiter  6  the  notion  of  a  core  compcment  and  comptment 
qiedfications  were  introdnced  to  provide  a  well-d^ned  meaning  to  compatibility  mqis 
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in  tenns  of  coosistaicy  rdations.  It  was  left  unsaid  how  die  ccmpoiiait  spedficatioiis  fit 
needier  to  fonn  the  top-levdqiecificatioiL  Addressing  dus  issue  could  lead  to  an  nqilana- 
tion  of  views  in  specifications  and  higher-level  abstxacdons  for  eiqilaining  the  design  and 
manqwlation  of  module  interoonnectioos. 

TVandatinn  functions  ensure  die  consistency  among  componmits  in  lelatum  to  each 
other.  ThiaringamngMdefinedmteniiaof  die  cnnidKtencymlatinns  and  the  core  compmienL 
But  do  we  in  fsct  always  need  to  define  die  core  conqionent?  Wb  do  not  need  to  in  the  sense 
that  we  do  not  always  start  widi  a  ^ledfication  to  write  a  program.  But  if  we  want  m  reason 
about  its  meaning,  dien  we  need  some  sort  of  ^pecHtoirion.  Once  die  core  comptment 
and  views  of  die  components  are  defined,  it  may  be  poisiUe  in  certain  cases  to  derive  the 
translation  functions  from  the  views  BMg  a  syniax-diiectBd  translation  scheme. 

hi  section  2.2  we  tfiscnsnd  the  difErent  approadies  to  looldng  at  correctness  diagrams, 
first  looking  at  verification  and  dien  askiqg  whether  it  is  possiUe  to  take  a  omstructive 
qiproadi  by  usiitg  transformaiians.  Behavioral  equivalence  [78]  handles  the  transitum 
between  data  ^lecificmions  and  lepresentations  in  a  more  general  way  than  abstraetkm 
functions.  Sannella  and  Tbritodd  [73]  develop  a  mrthodology  for  fonnaal  devehqanrot  of 
programs  baaed  on  dus.  Feiha|istrandation  functions  can  be  geaeralired  in  die  direction  of 
behavioral  equivaknce  where  trnafocBiations  are  applied  to  die  consisieiicy  lelatimis  (eg., 
using  real  relations  as  in  ftolog).  Cuirendy  die  mediod  is  restricted  to  using  functional 
impkamtations  of  dieae  relations  (/.«.,  oonqiatibility  imqis). 
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Appendix  A 
Notation 


Pkngram  notation.  Examples  use  typewriter  font  for  data  types,  lower-case  greek 
letten  far  type  variables,  sans-serif  ft»t  for  fimctums,  and  italics  for  variables.  The 
prodnct  type  constructor  x  binds  more  ti^ttiydian  die  fimctimi  type  constructor 


Notation 

Dexrtpdon 

Ftmctioa  definition. 

(x,y> 

‘nqileoonstnicton 

sxt 

ftodnct  type  oonstructon 

f 

listooostmcioc 

m 

Set  type  constructor. 

Lt^cal  implication. 

Ai:r.e 

I  jwntidf^  abstraction- 

fog 

Function  composition. 

\ 

Domain  lestrictioi  opeiatos: 

0 

Fimctional  overriding  operaton 

Abs,Rep 

Qeaie  an  abstractun,  reveal  die  underlying  rqnesentatuHL 

Conqponent.x 

Qualified  name  of  a  type  or  operad(»  in  a  comptment 

{  C|  1  ...  1  c«  } 

Alternative  solutions. 

map'; 

Consistency  relation  between  componaits. 

maPn/ 

Compatibility  map  fiom  one  component  to  another. 

span,  unspan 

Thmriadon  functions  firom  (»e  component  to  an  aggregate. 

vugequakon 

The  variable  satisfies  the  equatum. 
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AppetuSxA.  Notation 


Domain  optnitioM.  Common  domain  opetatiais  and  constantt  tiat  ate  used  in  die 
definitioiis  of  die  oompooeitt  opersdoos  and  Ae  compatibility  maps. 


Operation 

Description 

[c] 

Create  a  sequence. 

e 

^ipend. 

1  con8(x,j) 

Add  elementx  to  die  beginning  (tf  seqnmice  s. 

I 

1 

All  but  last  element  and  last  elmnent  of  a  sequoice. 

hd(f).tl(s) 

Rrst  element  and  rest  of  a  seqoMice. 

nullO 

PredicatB,  is  the  sequence  emp^? 

rev(f) 

Reverse  a  sequence. 

‘nl* 

Newline  character. 

*1* 

Control  L  character 

‘•P* 

Space  character: 

«s 

Hie  cardinality  of  die  sequence  5. 

sU] 

Subsequence  s  from  die  beginning  to  i. 

s[L] 

Subsequence  of  s  from  i  to  the  mid. 

slQ] 

Subsequence  of  s  from  i  to/. 

s[i] 

Hie  dement  of  die  sequence  s. 

[|D 

Setcoostructon 

xes 

Set  membership. 

(ixin>iD 

Hie  set  v^iose  demmits  satisfy  die  predicate 

(*inxB 

An  dement  diat  satisfies  die  jnedicatB  P. 

Auxiliary  ftmctkms.  Special  poipoae  functions  that  are  used  in  die  definitions  of  die 
component  operations  md  die  compatibili^  maps. 


Functkmntttne 

Dexription 

Ghar82page8(s) 

iines-1o-chars(i) 

nlp(c) 

rdpofiCf) 

nurnnKs) 

npao«8(s) 

parseCs) 

Parse  a  sequence  of  characters  into  a  sequmce  of  pages. 

Parse  a  sequences  of  lines  into  a  sequence  of  characters. 
Predicaie,  is  die  diaracter  a  newline? 

Hie  newline  positions  in  die  sequence  of  characters  s. 

H»  number  of  newlines  in  the  sequence  of  characters  s. 

Hie  number  of  pages  in  the  sequmice  of  diaracters  s. 

Parse  a  se^ience  of  characters  hdo  a  sequence  of  s-ejqnessions. 

Appendix  B 
Glossary 


Abstract  interface.  The  aqrancd^pes  and  signatures  die  (^>erat)ors  in  a  module. 

Agsregate  dellidtion.  An  aggregate  definition  is  a  Tenement  of  die  aggregate  spedfi- 
cadon.  The  data  rquesentation  is  defined  as  die  product  of  the  comptnent  data 
rqaesentatioas  and  the  operations  are  defined  in  terms  oi  the  cmnponent  opoadons 
as  data  transfonn  procedures. 

Aggregate  inqilonaitatian.  An  aggregate  implementation  is  arefinement  of  the  prototype 
providing  an  **efiBcieof*  implenientatuxi  of  die  datatype. 


Aggr^ide  proto^rpe.  An  aggr^ate  prototype  is  a  refinement  of  die  aggregate  definition 
where  the  data  tranafocm  procedures  have  been  transformedintofuncdtxialdefinidons 
to  prodnce  die  first  executable  system. 

Agpvgatespedficatiaii.  An  aggregate  qiecificadon  is  a  spedficarion  of  a  data^pe  coor 
stcuctedfiramaooikcdoDofooinpoiieiitsaiidconsistnicyreladoQS.  Eachopeiadon 
in  a  component  induces  a  cone^x»dingoperatk»  in  die  aggregate  that  maintains  die 
consistency  of  die  components. 

Convatibiiity  map.  A  compatibility  nuy  is  a  function  diat  respects  die  coosistmicyrelar 
tkm.  It  translates  one  componrat  representation  into  ano^represmitation. 

CooqMBciit  AcomponentdefinesacoUectionofoperaticHisdiatmayQrmaynmconstitute 
adata^pe. 

Consiatency  rdatioiL  Givoi  a  collection  of  impkmentations  for  a  common  definition,  a 
consfaaency  relation  provides  a  cone^xmdenoeb^ween  die  data  objects  manipulated 
in  one  implementation  from  those  in  another. 

DnlatrmMftirBpmoedinm.  Data  transfonn  procedures  define  altonative  imphm^ta- 
tionsondatarqiresentatioos.  Th^  may  take  one  of  two  forms: 
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AjqtendixB.  Glossary 


1.  GiveaaprogramfusingadatarqsesaitatioQZ>aiidafuiictioa,span,diattraiis- 
lates  elraaents  ci  the  daa  iqnesentadon  D  to  elements  of  the  data  representation 
ly,  we  define  f  as: 

f(8pan(<0)  <=  8pan(*c<0) 

2.  if,  instead,  diere  is  a  function,  unspan,  tiuu  translates  dmnents  oS  the  data 
representation />' to  donents  tile  darn  represmitatimi  i>,  we  define  f  as: 

unspan(f(4»  <=  f(unspan(4)) 

Projectioii.  Projection  functituisini^  an  aggregate  data  object  to  a  cmnponent  object 

Span  md  Unapan.  A  qum  function  is  a  mapping  fimn  (me  component  into  the  aggregate 
of  all  reachable  components  (i^.,  omnected  by  compatibility  mq>s).  An  unspan 
function  is  a  miqiping  firom  some  aggregate  ai  compcxmnts  into  the  componmit  that 
can  be  reached  by  all  of  timn. 

SpcdaUzatioii.  The  spedalizatum  process  (optimizes  a  program  to  take  advantage  of  tim 
ccmtexx  that  it  ippears  in.  This  is  acctxnplished  through  transformations  such  as 
apose,  incorporate^  release^  sh^^  and  translate. 

IWmsIatkai  ftmctian.  A  translation  function  is  a  functum  tiiat  translates  one  data  repre¬ 
sentation  into  another  tepresentaticm.  The  planning  functions,  span,  and  its  inverse, 
unspan,  and  compatibili^  mips  are  all  examples  of  translation  fimctums. 

View.  A  view  defines  how  an  implementaticm  satisfies  a  qiecificatkm  and  consists  of  a 
nupping  firom  the  sorts  of  a  qiedfication  P  to  tiie  sorts  of  an  implementation  /,  and 
a  nupping  firom  tile  (pexations  P  to  the  (peratkms  of /. 


Appendix  C 


TVanslatii^  Representations 


This  section  enumerates  the  ellided  steps  in  Sectitm  3.U  of  deriving  an  implementation 
for  move-right  tm  the  aggregate  data  structure  based  on  the  component  implementation  of 
move-right  in  Buf  i.  Recall  die  data  structure  for  the  buffer  definition. 


type  buf  =  Buf  of 

(intxch* 

X  ch*  X  ch* 

X  (intx  int) 
X  line*) 


— pdnt  of  editing  and  text  in  the  buffer 
— diaiacters  to  the  left  and  ri^  of  point 
— die  line  and  character  position  of  point 
— lines  in  the  buffer 


We  Start  with  the  definition  of  move-right  from  Figure  3.4. 

unspan(move-rlght(Buf(p,  i,/,  r,  {Ip,  cp),ts)))  <= 

Bufi.move-right(unspan(Buf07,  t,  /,  r,  {lp,cp),  ts))) 

Recall  that  move-right  was  defined  in  the  Buf  i  component  The  translation  function 
translates  the  data  aggregate  into  this  component  representation. 

unsparKBuf(p,r,/,r,{ii»,ty»>.tj))  <= 

Bufi.Buf({p  I  #/  I  #(l2c(tt[>^-l]))+l  +  q»),  {r  I  /@r  |  I2c(tt)  }) 

The  compatibility  mqis  have  already  been  unfolded  in  unspan  to  simplify  the  presentation. 
(12c  is  an  abbreviation  for  iines-ttxfrars.)  Since  the  definition  of  unspan  does  not  change, 
it  is  not  repeated  below.  Thoe  are  three  ways  to  accomplirii  the  translation  of  the  aggregate 
into  the  Buf  i  component  Extract  Buf  i  from  the  aggregate  directly,  or  use  one  of  the  two 
compatibility  miqis  to  translate  Buf  2  or  Buf  3  (extracted  from  the  aggregate)  into  Buf  1.  All 
of  the  three  choices  must  be  included  here  to  ensure  consistency  in  die  aggregate. 

The  aim  of  the  transformations  is  to  manipulate  the  qieration  to  obtain  a  definition  of 
move-right  that  operates  cm  the  aggregate  diiecdy.  Though  the  implementation  of  move-right 
(and  the  other  operations)  wiU  change,  the  meaning  of  tte  Buf  type  remains  the  same.  First 
the  unspan  operation  is  mechanically  “unfolded”  in  the  body  df  move-right. 

un8pan(move-right(Buf(p,  t,l,r,  {lp,q>),  ts)))  •«= 

Bu£i.move-right(Bu£i.Buf({p  |  «/  |  *(l2c(tf[-4i-l]))-t-l  +  cp},  {r  |  /#r  |  I2c(ts)})) 
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Appendix  C.  Translating  Rq>resentations 


Next,  the  onnptmrat  definition  of  move-r^ht  is  mechanically  ‘^unfolded.” 

unspan(move-fighKsaf(p.t./,r.  (lp,cp),tsyii  «= 

Bufi.Bu£(<p  +  l  I  #/+l  I  (#(l2c(ts[Ji»-ll))+l  +  <?>)+l  },  {t  I  /@r  I  I2c(ts)})) 

We  anticq>ate  having  to  satisfy  tiie  constraint  that  the  character  index  imain  within  die 
current  line  by  introducing  case  analysis  for  when  the  pdnt  of  editing  is  at  a  litre  boundary 
and  the  qieratiQn  crosses  the  boundtuy.  The  point  of  editing  is  at  the  end  of  a  line  whra 
the  character  positicm  is  equal  to  tire  length  of  the  current  line,  q>  »  Hts [(pl).  Tbe  true 
branch  of  tire  conditional  is  specialized  to  set  the  value  of  to  #(cs  [1p'\ )  and  the  resulting 
ejqncsatm  is  simplified. 

unspan(inove-fight(Buf(p.r./.r,  (b>,(v),ts))) 

Bufi.Buf({p+l  I  #/+l  I  *C2c(fs[Jp'-l]))*l*cp’),  {t  I  /@r  I  I2c(tt)}) 

Using  unspan,  we  know  how  to  nuqi  the  aggregate  to  tire  Buf  i  component  If  we  could 
obtain  tire  inverse,  then  deriving  a  new  implementatitm  for  operations  on  the  aggregate 
would  be  easier.  We  simply  map  tire  aggregate  into  the  cmnpmrent,  perform  the  cmnponent 
qreratioo,  and  thainuq)  tire  compmrent  back  into  the  aggregate.  Obtaining  the  inverse  may 
not  be  practical  since  dte  translatitm  function  may  not  always  be  one-toHure,  aikl,  even 
it  were,  there  may  be  no  easy  way  to  derive  it  Rather  than  coming  iq>  witii  the  inverse 
explicitly,  it  is  sometimes  possible  to  use  syntactic  manipulatifflis  and  simplificatirms  to  in 
effect  **mvext”thetranslati(Mifuncti<m.  This  is  accomplished  by  simplifying  the  expressions 
to  match  tire  new  representation  expressed  in  the  translation  function. 

Take  for  example,  the  inversicxi  of  /.  Tire  translation  function  and  the  preceding 
definiticm  of  move-right  are  shown  below  where  expressions  not  depradent  on  /  are  ellided. 
The  qtproach  is  to  use  simplification  rules  to  maitipulate  the  instances  of  /  in  move-right  to 
match  tire  conespcmding  instances  in  the  translation  function. 

unspan(Bu£(p,t/,r,((p,q>),tj))  <= 

Bufi3u£({...  I  #/  I  1  ler  1  ...» 

unspan(nriove-rlghtCBu£(p.  t/.r.  ^ 

kt ...  Id 

Bufi.Buf({...  I  #/+l  I  ...},  {...  I  I  ...» 

Using  tire  simplification  rule,  #/  +  1  #(/  @  [hd(r)»,  we  get  #/  -i- 1  in  the  definitimi  of 

move-right  to  match  #/  in  tire  defiiution  of  unspan.  This  adds  a  new  constraint  that  after 
moving  rig^t,  the  irew  sequence  to  tire  left  of  the  point  will  be  the  old  sequence  with  the  first 
element  of  tire  right  sequence  qtpended.  Using  the  simplification  rule,  r  =  [hd(r)]  @  ti(r), 
we  get  the  other  instance  of  /  to  meet  this  new  constraint  This  is  where  insights  about  the 
domain  from  tire  develqrer  are  needed  (in  this  and  the  following  step). 

unspan(move-right(Buf(p, r./.r.  llp,cp),u)))  ^ 

let  « iftp  »  *((1  [i!p] )  then  1  ebe  1  in 

Buf,.Buf({p-H  I  #(Z#Ihd(r)])  I  #(l2C(W[Ji»'-l]))+l  +  q»'}, 

{t  I  /#Ihd(r)l©tKr)  I  t2c(tt)» 
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The  motivadcm  for  the  next  step  is  to  satisfy  the  restriction  (from  the  ccmstraint  rm  the 
comp(»mit)  that  the  character  position  remains  within  the  current  line.  We  use  a  version  of 
the  simplificatirxi  rule: 

#(l2c(tj  [4p  -  1  ] ))  + 1  +  #(«s  )  + 1  =  #(l2c(tJ  [Jp] ))  + 1 

This  rule  states  Aat  Ae  length  of  the  preceding  lines  and  the  current  line  is  equivalent  to  tlw 
lmigth(tf  all  lines  preceding  and  including  die  current  line.  Instead  of  moving  the  character 
positicm  past  die  line  boundary,  we  increment  die  line  index  and  reset  the  character  position 
to  the  beginning  of  the  next  line. 

unspan(move-right(Bttf(p.r./.r, 

let  s  if  «  #(tt[(p] )  tiMB  (p + 1,0  else 

Bufi.Bu£({/»+l  I  #(i#[hd(r)])  I  #(l2c(tJ[J!p'-l]))+l  +  cp'}, 

{t  I  /@[hd(r)l@tl(r)  I  I2c(tt)}) 

Now  diat  all  instances  of  the  old  representation  tqipear  in  the  context  of  the  new  represen¬ 
tation,  unspan  is  mechanically  ‘Tolded.” 

unspan(fnove-iight(Buf(p,r./.r.  (Ip,cp),ts)))  <= 

§(fs [Ip})  tbealp-t- 1,0 dBtlp,q>+l  in 
unspan(Buf(p+ 1,  t,  /©  [hd(r)i,  tKr),  {lp',cp'},  ts)) 

Choose  the  solution. 

move-right(Bu£(p,r,/,r,((p,(:p),tt))  ^ 

let  If/, ^  a  if<p  «  i{ts[lp})tbenlp+ 1,0 dae  Ip, in 
Bu£(p+ 1,  t,  /#  [hd(r)],  tl(r),  {lf/,q/),  ts) 

A  new  implementation  of  move-right  has  been  dmived  that  qierates  on  the  aggregate  data 
structure  direcdy. 
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Appendix  D 

Shifting  Computation 


This  sectum  enumerates  the  ellided  steps  in  Sectum  3.1.6  involved  in  shifting  computation 
of  newline  infonnatitm  in  next-line  (in  the  prototype)  to  the  other  opmaticms  that  generate 
die  datatype,  such  as  makebuf  and  move-right  In  the  new  implementation,  next-line  is  able 
to  lode  up  the  newliiw  infonnadmi  it  needs  dixeedy,  while  makebuf  and  move-right  need  to 
do  extra  work  to  maintain  diis  information. 

Recall  the  data  structure  for  the  buffer  prototype. 


typebufsBuf  of 

(intxch* 

X  ch*  X  ch* 

X  (intx  int) 
X  line*) 


— p(^  of  editiiig  and  teaa  in  the  buffer 
— diamctcntodieleftandrij^ofixant 
— tbe  line  and  duracterpositioo  of  point 
—  lines  in  die  buffer 


We  start  with  the  definidtnis  for  the  buffer  tolerations  from  Hgure  3.5.  We  have  chosen 
a  soludtni  for  show-char  and  have  defined  span  according  to  the  observations  made  in 
Sectitm  3.1.6.  The  let  statement  in  move-right  has  been  unfolded  in  order  to  simplify  the 
presentation. 

makebuf  ^  Buf(0,  [],  [1.  (1,  (0,0),  (J) 

move-right(Bu£(p,r,/,r,((p,qi),n))  ^ 

Buf<p-f-l,  t,  /#[hd(r)i, 

Vqr»t(tsllp])t^0dxq>+1,  ts) 

8how-char(Bu£(p,r,/,r,((p,tp},n))  ^ 

tlp-1] 

next-line(Bu£(p, (s)) 

lctd> (nlpo^n))[(p]  - (nlpo8(n))(4r - 1]  in 

Bu£(p  +  d,  r,  /#r[-d],  r[d+l-],  {lp*l,q>),  ts) 

The  translatitm  functitm  records  die  software  develqier’s  requirements  to  qptimize  the 
prototype. 

^)an(basBu£(p,r,l,r,{(p,(p),n))  <=  Bu£'(p,  r,  fas(p,  ii/asnlpo8(n)) 

Since  the  definition  of  span  does  not  change,  it  is  not  rqieated  in  the  definitions  below. 
New  definitions  for  the  operatitxis  are  defined  as  data  transform  procedures. 
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AppendixD.  Skating  Computation 


makebuf  <=  span(makebuO 
it»w-riohf(8pan(Buf(p.f./.r.  ts)))  ^ 
8pan(move-rlQhKBuf(p,  r.  z,  r.  m 

gtiOW-^(8pan(Buf(p, z.Z.r.  {Ip,cp},ts)))  <= 
8hoi««Siaii»u£(p,  1. 1,  r,  (ip,cp),  ts)) 
Dffifcy!3flispan(Buf(p,r,Z,r,{(p,«y),ti)))  «= 
8pan(next-line(Buf(p,  /,  /,  r,  ((p,q»),  tj))) 


The  buffer  q)erati(m  definitioiis  are  mechanically  “unfolded.” 

makebuf  <=  span(Buf(0,  [],  11.  [],  {0.0),  (])) 

move-rlohf(span(Buf(i>.z./.r.  lli>.ep),ts)))  «= 

8pan(Buf(p  4- 1,  t,  /  #  [hd(r)],  tKr),  ir2;p  >  «(<$  [{p] )  thee  (p  4- 1  dse  Ip, 

if<7s#(u[i^])then0clse<9>4-l,  ts)) 

^mdit^ispan(Bxif(p,t,t,r,  {lp,cp),ts)))  ^ 
ttP-1] 

QffilljQfil(span(Buf(p,l,/.r,{^,<9»),tt)))  c 

apanOet  J « (nlpos(ts))  [(p]  -  (nlpos(ts))  [(p  >  l]  ie 

Buf(p4><z,  r,  z#r[-<f],  r[<i4-l«],  {lp*l,q>),  ts)) 

Next,  apsn  is  mechanically  “unfolded”  <xi  the  lighdiand  side. 

makebuf  <=  BufTO,  [  ],  0,  nlpos([  ])) 

movB-fiQhf(8pan(Bttf(p.t.Z.r.  {lp,cp),u)))  4= 

t,  Itq>mi(tsl^])ftimlp+lt3aelp,  nlpos(i3)) 

8tiO!iy-char'(8pan(Bttf(p,f.z.f.  {ip,cp),ts)))  <= 

tlp-l] 

Dfi2ddtofl!(span(Bu£(p,<.Z,r,{^^  4= 

Buf>+((nlpos(t»))[{p]  -(nlpos(tj))[^- 1]), »,  Ip-t-l,  nlpos(tt)) 


Since  the  character  position  within  the  current  line,  cp^  will  no  Itmger  be  cmnputed, 
all  references  to  it  must  be  transfonned  into  an  expressum  that  uses  data  that  will  still  be 
computed  (i.e.,  p,  t,  (p,  and  n4x)S(Cf)).  The  espresskn  cp  »  #(»  [(p] )  is  transfonned  into 
n|p(f  [p])  ediich  nates  that  checking  to  see  if  ^  character  posititm  is  at  the  end  of  a  line 
is  equivalent  to  checking  if  die  current  character  is  a  newline.  (The  details  are  omitted  for 
die  sake  of  brevity.)  As  in  die  previous  derivadcm,  die  guiding  modvatitm  is  to  manipulate 
die  definidon  so  that  all  instances  of  the  old  representation  qipear  in  the  context  of  the  new 
representation. 

makebuf  Bu£'(p,  [),  0,  nkioeai)) 

mov»>riQhf(apan(Buf(p.z./.r. (lp,cp),ts)))  «= 

Buf'(p4>l,  t,  tfnlp(zcp])theBi^4-ldse{p,  ripos(ts)) 

i&gsK:tfad(span(Bu£(p,t,Z,r,(4>,(p},tt)))  4= 

<CP-11 

asadtafi!(span(Buf(p,t,/,r.{(p,<p),(s)))  4= 

Bu£V+((nlpoe(tt))t<pl  -(nlpoe(tt))i<p-  ii),  t,lp*i,  nlpo8(tt)) 
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Introduce  a  kt  abstraction. 

makabuf  ^  Buf"(P,  [],  0,  nfposai)) 

moye-fighf(8panCBuf(p.t./.r.  (Ip,cp),m  «= 

MpytXnlmp,  t,  (p,  r^po8(tt)ia 

Buf'(p-»-l,  t,  ifnlp(([p])thcat-t-ldset,  nl) 

show-char'fspanteufto.t./.f. 

1ietp,t,i,iilmp,  t,  Ip,  nlp08(tt)ia 

0ffi£fcfiDfli8pan(Bu£(p.  /,  /.r,  {fp,ep),m  <= 
yAp,t,i,tdmp,  t.  Ip,  nlpo8(ts)ia 

Bu£'(p-i>(ii/[i]  -Ji/[i-ll),  /,  <  +  l,  Hi) 

Introduce  an  abstiacti(»  boundary,  x  =  Rep(Ab6(z)).  Here,  Buf '  is  used  for  introducing 
the  abstracticm  boundary  and  Rep'  for  uncovering  the  representation. 

makebuf  c  Bu£'(p,  [],  0,  niposd])) 

move-riQht'(8pan(Buf(p.<./.r. {Ip,cp),ta)y)  -<= 

Rep'(Bu£'(p,  i.  Ip,  n^p06((s)))ia 
Bu£'(p-»-l,  t,  ifnlp(/(;p])theui>i>lcbei,  hI) 

8hQw<haf'tspafWBufto.t./.r. 

Rep'(Bu£'(p,  t.  Ip,  nlpo8(tt)))to 

rtP-ll 

lctp,r,j,ii/«  Rep'(Bu£'(p,  f,  <p,  n4)os(tt)))ia 

huf'Ip^Odli]  -HlU^l]),t,i*l,Hl) 

Mechanically  **fdtd”  span  on  die  rightiumd  side. 

makabuf  ^  Bu£'(0,  [],  0,  nlpo6([])) 

move-right'(8pan(Bu£(p,<./,r, {lp,cp),m  ^ 
ktp,t,i,Ht^  Rep'(apan(6))  in 

Bu£'(p-»>1,  t,  ifn|p(r[p])acn  j-fldie  j,  nt) 

gteify-Chatl(<pan(Bu£0>.t./.r,  [lp,q>),m  <= 
lBtp,t,i,Hlm  Rep'(8pan(6))  k 
tCp-l] 

QfiSldiDfi:(span(Bu£(p,r,/,r,((p,(7),tt)))  ^ 
ltip,t,i,Hl»  Rep'(8pan(^))  k 

Bu£'(p  +  (jl/[i]  -Jl/W-ll),  Hi) 

Since  all  instances  of  the  old  representation  appear  in  the  context  of  die  newrqnesentation, 
8pan(b)  is  rraamed  to  b'. 

makebuf  <=  bu£'(0,  [],  0,  nlpo8([])) 

mov»-righf(tO  <= 
kt/»,r.<,al-Rep'(bOk 

Bu£'(p<f  1,  t,  irrtip(r(p])thcB<-t-lelMt,  hT) 
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Aj^ndixD.  Shifting  Computation 


shcw-chaKciO  <= 

ktp,t,i,iil*  Rep'(frO ia 
tlp-l] 

raxt-Hne'C^O 

>  Rep'(^^  tai 

Bu£'(p-f(M/m  -.||/[j-l]),  f,  j-t-l,  Hi) 

As  an  alternative,  patterns  are  used  on  the  lefthand  side  to  destructore  the  datatype  instead 
of  using  Rep  explicitly  on  the  lighthand  side. 

makebuf  ^  Buf'CO,  [],  0,  []) 

move-right'(Bu£'(p,f,i,ii/))  <=  Bu£'<p-f  l,  t,  if  nip((Cp] )  tben i -t- 1  dse i,  ni) 

8ho«v-chaK(Buf'(p,/,i,iiO)  t[p-i] 

next-line'(Bu£'<p,t,t,jiO)  •«=  Bu£'(p+ - n/U - 1] ,  r,  t-i- 1,  ni) 

In  die  new  implementation,  die  computation  is  shifted  away  firom  next-line  so  diat  next-fine 
simply  looks  iqi  die  position  of  the  newlines  surrounding  die  current  line  diiecdy.  The 
transformation  allows  one  to  get  firom  the  prototype  rqnesentatimi  to  diis  one  in  a  ccmaolled 
manner. 


Appendix  E 

Int^ating  Components — ^Proofs 


This  section  contains  die  pnxjfs  for  Sectum  6.1.4.  Each  sectimi  starts  with  an  aggregate 
definition  and  shows  die  details  about  how  the  definidra  satisfies  the  axioms  (xmiprising 
the  aggregate  spedficatiCTL 

«tanpfpi2(op(«gg))  -  opiCprpjjCagg)) 

*d««P»oi2(agg)  mart  proj,(agg)  prpbWa^g))  mart  proji(op(agg)) 

«di»prois(agg)  mart  projj(agg)  probtoptagg))  map?  prpjjtoptagg)) 

axknprpiitagg)  mart  P«^i(agg)  *=►  P«)b(op(agg))  mart  prQji(0P(agg)) 

Product  rt  the  Rqircacntations 

Here  is  a  simpte  definition  for  die  aggregate  where  die  data  structure  is  the  product  of  the 
component  representations. 


GhpeKopi.  mapi^a,  mapi^„  mapj^,.  map,^i,  mapa^j,  mapj^j 


prqia(Agg(ci,ca,C3))  -<=  C2 

prpg-‘(x)  <s  Agg(mapa^,(r),  x,  mapa^jW) 

in 

0P(agg)  -e=  prog-‘(opa(proja(agg))) 


^  need  to  ensure  that  the  above  definidai  satisfies  the  aximns  that  define  dw  aggregate. 

a  Axiom  1.  The  first  axiom  holds  because  we  derived  the  new  definititm  from  it 
However;  we  most  justify  die  assumptions  made  during  the  transformation  st^s 
about  die  inverse  projection  being  injective  and  a  Irttinvmse  of  die  projectioit  In  so 
doing,  a  definition  for  die  inverse  projection  is  obtained. 

lb  show  that  proj^*(proja(x)) »  x,  die  proof  goes  as  follows: 
Pmj2*<Prob(*gg(ci.C2.C3)))  ■  Agg(ci, 02,03) 

Rrstunfrtdproja* 
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AppttuUxE.  Inugrating  ComportenOh-Proofs 


proji'‘(c2)  =  Agg(ci,C2,C3) 

and  then  unfold  projj*. 

Agg(map2-.i(c2)>  ci,  lTiap2_3(c2))  «  Agg(ci ,  C2,  C3) 

The  ccxnponents  are  consistent  by  definiticm,  so  that  ci  and  03  can  be  expressed  in 
terms  of  C2,  diat  is,  ci  =  map2_|(c2)  and  C3  =  map2_3(c2). 

Agg(ci,  C2,  C3)  »  Agg(ci  ,02,03) 

•  Ajdom2.  Start  widi  die  axiom, 

proiaCagg)  maf4  proji(agg)  pfOja(op(agg))  mapj  proj,(op(agg)) 

and  prove  die  consequent, 

prc82(op(agg))  maj^  pfOj,(op(agg)) 
by  first  unfdding  the  definiticm  of  op. 

Proj2(prpg-‘(op2(prpjj(agg))))  map^  prpji(pioH-‘(opj(prpj2(agg)))) 

Then  simplify,  using:  proj2(pro£' V))  =  x  and  projj(prDj^*(x))  =  map2_i(x). 

0P2(pr0fc(agg))  mapj  map2^i(0P2(prpj2(agg))) 

Factor  out  die  cmnmmi  subexpressimi  to  make  it  more  obvious. 

X  mapi  map2^,(x)  where  x»op2(prpj2(agg)) 

This  is  true  by  definiticm  of  map|. 

,  •  AxUmS.  Showing  diat  die  diird  axiom  holds  is  similar  to  the  proof  for  Axiom  2. 

a  Axkm4. 

Start  with  die  axiom, 

prpj3(agg)  mapj  prpj,(agg)  prpbWagg))  mapj  proj,(op(agg)) 

and  prove  the  consequent. 


prpj3(op(agg))  mapj  prpj,(op(agg)) 
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by  first  unfolding  op. 

projj(pfpK'‘(OR,(prpj2(agg))))  mapj  pr{^',(proH-‘(ORi(proj2(agg)))) 

Then  fold  the  definititMis  of  niap2_»3  and  map2_»i, 

maP2^s(0P2(proi2(agg)))  mapj  map2^,(op2(pro|2(agg))) 
and  factor  out  the  ctunmcm  subexpression. 

mapj^jOt)  mapj  mapj^iC*)  where  x  =  opjCprojjCagg)) 

Substitute  maps^iCmapj^sCx))  for  map2_»i(x), 

nwp2_j(x)  mapj  map,_,(map2^j(*))  where  x = op2(proj2(agg)) 
and  factor  out  the  axnmon  subexpression. 

y  mart  fnaPi-iCy)  ^  *  <^(proj2(ag9))  ■»*  y  =  mapi-jW 
This  is  true  by  definition  of  map]. 

Rdmploiieiiting  the  Operations 

Given  a  definitUm  of  die  tqietatum  in  one  componoit,  we  derive  alternative  implementations 
for  the  other  components  using  data  transform  definiticms  and  then  define  the  aggregate 
qieratimi  in  terms  of  these  comptment  pperatitms. 

Given:  opz>  mapj^i,  mapj^j 

local 

0Pi(map,^,(c2))  <=  map2^,(op2(c2)) 
map,^j(op,(c3))  •«=  opi(map,^j(c3)) 

in 

OP(Agg(ci,C2,C3))  Agg(cJ,  cj,  rt) 

where  rt  »  op,(ci) 
and  rt  «  opjCci) 

and  rt  «  0ft(c3) 

end 

•  Axiom  1.  Start  with  the  axiom, 

proia(op(agg(ci,c2,C3)))  «  op2Cprpi2(Agg(ci,C2.c3)) 
and  take  the  second  projection  on  die  righthand  ride. 
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Appendix  E.  Integrating  C<mq)onents—Prop^ 


prO!jj(op(Agg(ci,ca,Q3)))  »  0Pi(c2) 

Unfold  op  and  take  the  sectmd  projection  on  the  lefthand  side. 

OP2(C2)  »  OP2(C2) 

•  Axiom2.  Start  with  the  axitnn: 

pre!i2(Ag9(ci,c2>cs))  mapj  P»o|i(Agg(ci,c2,c3)) 

proj2(op(Agg(ci.cj,C3)))  mapj  pfpj,(op(Agg(ci, 02,03))) 

lb  prove  the  consequent, 

proj2(op(Agg(oi,P2,03)))  proj,(op(Agg(oi,02,03))) 

define  an  implementaticn  of  the  relation  as  a  ctHnpatibility  map  tiiat  maps  (xie  com- 
fxmait  into  the  other;  that  is:  X  map^  y  =  >  »  map2_i0c)* 

P«>ji(op(Agg(oi,c2,03))))  «  map2_,(prpj2(op(Agg(oi,02,C3)))) 

Unfold  op  and  take  the  projection. 

op,(ci)  i  map2^,(op2(o2)) 

Since  the  rigjithand  side  matches  the  body  of  opi,  fold  the  (e^qnession  procedure) 
definitimi  of  opj, 

0Pi(oi)  »  op,(mapi^,(o2)) 

ai^  then  substitute  ci  for  map2_i(c2)  which  is  given  by  tire  antecedent 

0Pi(Oi)  *  OPi(Ci) 

•  AxUm  3.  Start  witii  tiie  axiom: 

pfpjj(Agg(0i,02,C3))  ma|^  proj2(Agg(oi, 02,03)) 

proj3(op(Agg(oi,C2,C3)))  maj^  prpj2(op(Agg(oi, 02,03))) 

As  above,  to  prove  tile  coosequrat. 


prqi,(ap(agg(oi,o2,03)))  ma|^  projj(op(Agg(oi,02,03))) 
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define  the  relation  in  terms  of  a  compatibility  mt^;  that  is: 

X  mapf  y  s  y  =  maps^aW- 

proi2(op(Agg(ci.C2.C3)))  »  map3_2(pr(^(op(Agg(ci,  02,03)))) 

Unfold  op  and  take  the  projection. 

0P2(C2)  »  nfiap,_2(0Pj(c3)) 

Since  the  righthand  side  matches  the  definitimi  of  OP3,  unfold  the  (expression  proce¬ 
dure)  definition  of  OP3, 

0P2(C2)  *  op2(map,_2(c3)) 

and  then  substitute  C2  for  map3_^2(^3)  which  is  given  by  the  antecedent 

OP2(C2)  »  OP2(C2) 

•  Axiom  4. 

Start  with  the  axiom: 

projjCagg)  mapj  prpj,(agg)  =»  prQj3(op(agg))  mapj  proj,(op(agg)) 

lb  prove  the  consequent 

proj3(op(agg))  mapj  pf(^i(op(agg)) 

first  define  the  relaticm  in  terms  of  a  compatibility  map: 

X  mapj  y  s  y  =  mapj^iCmapj^aCx)). 

proji(op(agg))  «  map2^i(map,^2CP«^(0P(agg)))) 

Unfold  op  and  take  the  projection. 

op, (01)  I  mapi^,(map,^2(op3(c3))) 

Then  unfold  the  (expression  procedure)  definition  of  OP3, 
op, (Cl)  i  map2^,(op2(map3_2(c3))) 
and  fold  the  (expressitm  procedure)  definition  of  op,. 

op,(ci)  I  op,(mapi,_,(map,^2(c3))) 

Simplify,  usdng:  ci  =  map2_i(nt€^3_,2(c3)). 
op,(ci)  -  op,(c,) 
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Appendix  E.  Integrating  Components— Proofi 


Showing  'nransitiyity 

Here  we  rdax  die  restricticHi  that  requires  any  two  cranponents  to  be  directly  connected 
by  a  compatibility  mi^,  to  simply  requiring  a  connectum,  possibly  through  some  number 
of  intermediate  comptments.  In  all  of  the  cases,  the  proof  for  Aximn  1  in  this  section  is 
identical  to  the  proof  for  Aximn  1  in  tte  preceding  section.  We  focus  on  Axiom  3  since  it 
is  the  interesting  case  where  the  omsistency  relation  cannot  be  defined  in  terms  of  a  single 
compatibility  miqp,  and  so  an  intermediate  compcment  must  be  used.  The  proofs  for  the 
other  aximns  are  similar  to  tile  ones  in  the  preceding  section  since  there  are  direct  translation 
fdnctimis  in  tiiese  cases. 

Case  1. 

Given:  opi,  mapi^a 

local 

0Pi(n»api^i(ca))  «:=  map2_i(op2(c2)) 

ops(map,^3(c3))  <=  map,^3(opi(c3)) 


in 

op(Agg(ci,C2,C3))  Agg(c;,  c^,  cj) 

nbare  cj  =  0Pi(ci) 
and  C]  s  0P2(c2) 
and  a  0P3(C3) 

end 

Unlike  the  proof  for  Axiom  3  in  the  preceding  sectitm,  to  prove  the  consequent, 

proi3(op(Agg(ci,C2,C3)))  mat^  proj2(op(Agg(ci, 02,03))) 

we  define  the  relatitm  in  terms  of  die  composition  of  the  compatibility  maps.  The  compo- 
....ats  are  ‘‘related’*  if  C2  can  be  translated  into  cj  using  the  composition  of  the  compatibility 
msps. 


prgjs(op(Agg(oi,  02,03)))  •  mapj^3(map2^,(proj2(op(Agg(oi,02,C3))))) 
Unfold  op  and  take  the  nrojectitxL 

op,(o3)  -  mapi_3(map2^,(op2(c2))) 

Fold  die  definition  of  0P|, 

opi(cs)  i  map,^j(op,(map,^,(o2))) 
and  dien  fidd  die  definitioo  of  OP3. 

opi(ci)  i  oft(rnap,^j(mapi^,(ca))) 

Simplify  using:  C3  »  niap|_3(map2_i(c2))  frcxn  tbe  antecedent 


Oft(os)  -  op,(os) 
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Case  2.  Similar  to  Case  1. 


Case  3. 


Given:  op2>  mapj_i 

local 

0Pi(map2^i(c2))  <=  map2_,(op2(c2)) 
map3^,(op3(c3))  .4=  op,(mapj_i(c3)) 


in 

op(Agg(ci,C2,C3))  «=  Agg(c',,  c^,  cj) 

where  c{  =  0P|(ci) 

and  =  op2(c2) 
and  cj  =  0P3(C3) 

end 

To  prove  that  this  definition  satisfies  the  axioms,  we  need  only  reconsider  the  proof  for 
Axiom  3  (since  the  others  remain  the  same).  Unlike  the  proof  for  Axiom  3  in  the  preceding 
section,  to  prove  the  consequent. 


pfOj3(op(Agg(ci,C2,C3)))  proj2(op(Agg(ci,C2,C3))) 

we  define  the  relation  in  terms  of  a  pair  of  cmnpatibility  maps.  The  components  are  ‘‘related” 
if  they  both  can  be  translated  into  some  common  form. 

map2_i(proj2(op(Agg(ci,C2,C3))))  =  maft_,(proj3(op(Agg(ci,C2,C3)))) 

Unfold  op  and  take  the  projection. 

mapi_i(0P2(c2))  =  mapj_i(opj(c3)) 

Fold  the  definition  of  opj  on  the  lefthand  side,  and  unfold  the  definition  of  op)  on  the 
righthand  side. 


0Pi(map2_,(c2))  »  op,(maft_,(c3)) 

Simplify,  using:  niap2_}(c2)  =  niap3_^i(c3)  from  the  antecedent 


opi(maft_i(c3))  -  op,(map,_i(c3)) 
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Appendix  E.  Integrating  Con^nents— Proofs 


Case  4. 

Given:  of^,  map,^2.  mapj^j 
local 

fnapi^2(0Pi(ci))  <=  op2(map,^2(ci)) 

0P3(mapi_3(ci))  <=  mapi_3(opi(ci)) 

in 

op(Agg(ci,C2.C3))  <=  Agg(cJ,  c^,  cj) 

where  c{  =  0Pj(ci) 
and  ci  =  0P2(C2) 
and  =  0ft(c3) 

end 

As  for  case  3,  we  need  only  ccHisider  the  proof  for  Axiom  3. 

pf(^(Op(Agg(ci,C2,C3)))  mat^  pf0j2(0p(Agg(ci,C2,C3))) 

We  define  the  relation  in  terms  of  some  intermediate, 

ax .  map,_2(x)  =  proj2(op(Agg(ci ,  C2,  C3)))  AND  map,_3(x)  «  proj3(op(Agg(ci ,  C2,  C3))) 

and  take  the  appropriate  projections. 

ax .  map,^2(*)  “  0P2(C2)  and  mapi^3(*)  *  oPsCcs) 

The  components  are  consistent  by  definition,  that  is:  mapi_2(ci)  =  C2andmapi_3(ci)  =  C3. 
The  antecedent  states  that  the  ci  component  is  indeed  the  same  in  each  equation. 

3x .  mapi^2(*)  -  0P2(mapi_2(ci))  AND  mapi_3(x)  =  opj(map,^3(ci)) 

Fold  the  body  of  opj  and  unfold  the  definition  of  0P3. 

ax .  mapi^2W  =  maPi-.2(0Pi(ci))  AND  map,_3(x)  =  mapi_3(opj(ci)) 

This  is  true  when x  is  equal  to  oPi(ci). 

Increiiiteitally  building  the  aggregate. 

This  section  demtmstrates  how  the  incremental  definition  ^own  bdow  satisfies  the  defini¬ 
tion  presented  in  Figure  6.8.  This  iqyproach  is  a  voificatitm  presentatitm  where  the  new 
definition  is  ’invented”  and  then  the  equivalence  between  the  old  and  new  definitions  is 
shown  using  the  usual  symbol  manipulations  of  fold  and  unfold. 


Ghwopi,  maft^, 

locd 

8pan(c2)  Agg,-(ci,  C2)  where  Cl  »  mapi_,(c2) 

un8pan(Agg(ci,c2,c3))  «=  Aggj({ci  |  mat^_,(c3) },  C2) 

la 

op|(8pan(c2))  8pan(opi(c2)) 

ur»pan(op(Agg(ci,c2.C3)))  ^  op,(un^)an(Agg(ci,  C2,  C3))) 
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The  following  insist  is  useful  in  comii^  up  widi  the  aggregue  dtfimtion  In  the 
previous  definition  of  op,  we  saw  that  it  contamed  the  following  subexpsessioo. 

. . .  c'l  a  0Pi(ci)  and  «  opjCca) . . . 

We  can  transfonn  a  pair  (tf  functions,  each  returning  a  single  value,  into  a  single  function  re- 
turning  a  pair  of  values.  That  is,  transfonn  C},  <4  »  opi(ci),op2(c2)  into  C|,  cj  >  opj(ci,  cz). 
Notice  diat  the  ctnnponents  are  now  computed  together  (in  a  single  fonoioo),  so  diat,  for 
example,  cz  is  available  to  compute  the  new  value  of  ci,  v^iich  the  designer  mig^t  use  if  it 
increases  efficiency.  We  can  then  repeat  die  process  and  cmnbine  the  result  with  die  diiid 
comptment  C3. 

Here  we  start  with  the  new  definition  and  follow  a  set^nce  of  transformatitxis  that 
dmnonstrate  how  it  is  equivalent  to  the  old  one  (in  Rgure  6.8). 

unspan(op(Agg(ci,C2,C3)))  -<=  op.(unspan(Agg(cj,C2,C3))) 

Unfold  unspan  on  the  righthand  side. 

unspan(Op(Agg(ci,C2,C3)))  ><=  OPi(AggK{ci  j  map,_,(C3)},C2)) 

The  compcments  are  consistent;  that  is:  ci  =  niap3_^i(c3)  and  ci  =  map2_i(c2). 

unspan(op(Agg(ci,C2,C3)))  ^  op.<Aggi({ci  1  map2^i(c2)},C2)) 

Fold  span  on  the  righthand  side, 

unspan(op(Agg(ci,c2,c3)))  *<=  op,<span(c2)) 

unfold  op,-, 

unspan(op(Agg(ci,C2,C3)))  <=  Aggi(mapi_i(op2(c2)),op2(c2)) 

and  then  fold  the  definition  of  opj. 

unspan(op(Agg(ci,c2,c3)))  <=  Agg,<op,(mapi^,(c2)),op2(c2)) 

The  ctmiponents  are  consistent;  that  is;  ci  =  niap3_}(c3)  and  ci  =  map2_](cz). 
unspan(op(Agg(ci,c2,C3)))  <=  Agg,<op,(map,^,(c3)),  0^(02)) 

Introduce  the  equality,  {  jc  |  x  }.  If  x  is  valid,  then  both  alternatives  are  valid  ways  to 
compute  the  value. 

unspan(op(Agg(ci,c2,c3)))  •«=  Agg,<{  0Pi(map,_i(c3))  I  op,(maft_i(c3))  },0p2(c2)) 

The  components  are  ctmsistent;  that  is:  ci  =  niap3_|(c3)- 

un8pan(op(Agg(ci,C2,C3)))  <=  Agg,<{0Pi(ci)  |  op,(map,_,(c3))},op2(c2)) 

Fold  the  definition  of  0P3, 

unspan(Op(Agg(ci,C2,C3)))  <=  Agg.<{  op,(ci)  I  map,_,(0p,(C3))  },OP2(C2)) 
fold  unspan, 

unspan(op(Agg(ci,c2.c3)))  unspan(Agg(op,(ci),op2(c2),op,(c3))) 

and  then  choose  a  solutitxL 

0P(Agg(ci,C2,C3))  <=  Agg(op,(ci),op2(c2),op,(c3)) 


